Who Controls the Enterprise Agent Stack?

Who Operates the Agent?

The hardest part of an enterprise agent is no longer getting it to answer. It’s deciding what it may do, how you test it, and who takes over when it fails.

OpenAI is packaging those decisions into a managed product called Presence. Launched on 22 July, it combines models with policies, approved actions, simulations, evaluations, guardrails and rules for escalating work to humans. The initial use cases include billing, insurance claims, sales and IT support. There’s also a Codex-powered improvement loop that proposes changes based on production sessions.

This isn’t self-service. Presence is limited to eligible enterprise customers, with deployments handled alongside OpenAI’s Forward Deployed Engineers or selected systems integrators. OpenAI says this produces an agent system that can improve continuously while remaining under organisational control. We don’t yet have independent evidence on reliability, cost or whether the proposed improvements lead to better production outcomes.

My read is that Presence is a bid to own the operating layer around the model. The model still generates the response, but the difficult enterprise work increasingly happens around it: permissions, testing, monitoring, escalation, change approval and evidence that the system behaved as intended.

That distinction becomes obvious when an agent can take consequential action. Consider a billing agent with permission to alter a customer account. Its conversational quality matters, but that’s only part of the risk. The organisation must also know which actions were available, why the agent selected one, whether the request exceeded a limit, when a human should intervene and what record remains afterward. If a later optimisation changes that behaviour, somebody still has to decide whether the change is safe to release.

Presence could shorten the path from a convincing prototype to a governed service because those controls no longer need to be assembled from separate products and internal systems. For enterprises that have spent months connecting model APIs to evaluation tools, policy engines, observability and human support queues, that integration has real value. This operational layer is where many agent projects slow down.

But convenience and dependence arrive together. Choosing Presence potentially means choosing one provider across the model, policy, evaluation and operational layers. That’s a much bigger commitment than calling a model API. Switching a model is one thing. Extracting years of policies, tests, action definitions, escalation logic and production evidence is much harder.

So these questions belong in procurement from the beginning. Can the organisation export its policies, evaluations and audit history in usable formats? How finely can it restrict access to production actions? What evidence is available when an agent decision is disputed? Who approves a change proposed by the Codex-powered loop, and who is accountable if it makes performance worse? Could another platform reproduce the controls, or are they expressed in concepts unique to Presence?

For regulated or high-consequence deployments, I’d also separate continuous improvement from automatic improvement. A system that proposes changes from production data can be useful. Allowing those proposals to bypass review would be a very different risk decision. The briefing doesn’t say Presence deploys changes automatically, so the practical issue is the approval model each enterprise negotiates and enforces.

The real test won’t be whether a demonstration looks neatly integrated. It’ll be whether organisations can show lower incident rates, faster controlled updates and clear audit evidence without losing the ability to change suppliers. Until those results exist, Presence is best understood as a promising operational package with a substantial architectural commitment attached.

That operational bottleneck isn’t unique to agents. Wherever AI increases the volume of plausible work, trusted human attention becomes scarce. GitHub is redesigning its security program around exactly that problem.

GitHub Filters for Signal

GitHub restructured its bug-bounty program on 22 July, explicitly citing rising report volume and low-effort or AI-generated submissions. The new rules apply to reports filed from 27 July.

The public program remains open, but GitHub is reducing payouts and adding HackerOne signal requirements. At the same time, it’s making an invitation-only VIP track permanent, with higher rewards and faster responses for researchers in that group.

AI can help researchers search code, generate test cases and investigate possible weaknesses. It can also produce polished reports for issues that are duplicated, poorly demonstrated or simply wrong. Every submission still consumes triage time, and an overflowing queue can delay genuinely serious findings.

GitHub’s answer is reputational filtering. Researchers who have already demonstrated good judgment get better access to rewards and response capacity. That may protect the security team’s attention, but it also raises the entry barrier for a capable newcomer who hasn’t yet built a reputation on the platform.

For researchers using AI-assisted discovery, volume is now a poor strategy. A useful report needs a reproducible path, a clear security impact, the affected component and enough evidence for GitHub to distinguish a real vulnerability from generated speculation. Sending a large batch of weak possibilities may actively damage a researcher’s standing.

What I’d watch next is whether the changes reduce false-positive workload without suppressing valid reports from new researchers. If strong first-time submissions consistently struggle to reach the better response path, GitHub will have traded one filtering problem for another. But the underlying message is sound: AI can expand discovery faster than it expands verification, which makes evidence quality more valuable, not less.

Now, from security triage to infrastructure. AWS is moving another difficult operational choice into configuration: the physical shape of an AI cluster.

Topology Becomes Configuration

AWS has added Elastic Fabric Adapter and EC2 placement-group controls to Amazon EKS Auto Mode and the open-source Karpenter project. Operators can now declare those settings through Kubernetes node pools instead of configuring them separately.

Elastic Fabric Adapter provides the high-bandwidth communication needed by distributed training and inference workloads. Placement groups control how EC2 instances are arranged. Cluster placement can favour throughput, spread placement can separate instances for availability, and partition placement can provide stronger failure isolation across groups of machines.

Moving these choices into node-pool definitions removes configuration friction. It doesn’t remove the trade-offs underneath. Teams still need to understand how their workload communicates, what capacity is available, how failures propagate and what the infrastructure ultimately costs.

What I find interesting is that accelerator performance increasingly depends on everything between the accelerators. Expensive GPUs waiting on network traffic are expensive idle capacity. AWS isn’t announcing a new model or chip here. It’s making the topology that keeps distributed systems productive easier to express, repeat and operate.

For teams running multi-node training or tightly coupled inference, the practical response is to test three things with a representative workload: throughput during normal operation, recovery when nodes or network paths fail, and total cost for the performance achieved. A configuration that wins a clean benchmark may still be the wrong choice if capacity is difficult to obtain or one failure disrupts the whole cluster.

If your workloads fit comfortably on one node, you can mostly ignore this. For everyone else, declarative topology is useful, but it also embeds more AWS-specific infrastructure knowledge in the Kubernetes layer. The easier a platform makes a sophisticated cluster to provision, the more carefully architects should document what would be required to reproduce it elsewhere.

That question of reusable infrastructure becomes more political when the operator is a government rather than a cloud customer.

Europe Builds a Shared Layer

The European Commission launched EuropAI on 22 July to jointly procure, test and deploy reusable European generative-AI components for public administrations. Its initial areas include legal simplification, urban planning and assistants that interact with citizens.

The planned outputs include technical components, deployment blueprints, compliance documentation and reusable applications. This is an infrastructure and procurement initiative. It isn’t evidence that those public services are already operating or producing better outcomes.

The potential advantage is less duplication. Instead of every administration separately procuring a model stack, designing a compliance process and commissioning similar components, EuropAI could provide foundations that multiple agencies can examine and adapt. Shared documentation could be especially useful for smaller administrations without specialist procurement and AI-governance teams.

The risk runs in the same direction. Reuse can spread good engineering, but it can also spread weak assumptions. A component designed around one legal process, language or accessibility standard may fail when transferred into another setting. A shared supplier decision can also concentrate dependence rather than create genuine sovereignty.

For public-sector buyers, a European blueprint shouldn’t be treated as approval for a local deployment. Citizen-facing systems still need testing against local law, language, privacy requirements and accessibility needs, with a clear route to human review when the system is wrong. Suppliers should expect to show how their components can be inspected, modified and operated across different administrative settings.

The evidence worth watching is practical rather than ceremonial: which components are actually reused, whether agencies publish credible evaluations, and whether local adaptation costs fall without weakening accountability. If EuropAI can deliver that, sovereignty becomes an operational capability rather than a procurement slogan.

Patch WordPress Now

A clean reset now, because this one needs action. WordPress released versions 7.0.2, 6.9.5 and 6.8.6 on 17 July to fix one critical and one high-severity vulnerability. The official notice describes a REST API route-confusion and SQL-injection chain that can lead to unauthenticated remote-code execution.

WordPress enabled forced automatic updates for affected installations, but background updating isn’t supported in every environment. Site owners, hosting providers and agencies should confirm that each affected installation is running the patched release for its branch, then investigate any site where the update failed or was disabled. According to WordPress, versions earlier than 6.8 aren’t affected. The forced rollout should reduce exposure across a fragmented ecosystem, but it doesn’t replace checking the installed version.

What Changes for You

Anthropic has also put a firm date on a piece of operational housekeeping. Access to the legacy Claude Workbench ends on 17 August 2026, one month after the change was announced. The experimental generate_prompt, improve_prompt and templatize_prompt API endpoints retire on the same date and will return errors afterward.

Claude Console users with material in the old Workbench need to export it through the migration banner or Organizational Settings. Developers calling the experimental endpoints need replacement logic deployed and tested before the deadline.

The awkward limitation is that this isn’t a lossless migration. Anthropic says the updated Workbench doesn’t support legacy saved prompts, variables or evaluations. An export preserves the data, but it doesn’t guarantee that the existing workflow can be recreated unchanged. Teams may need to rebuild prompt structures and evaluation processes manually, then test the resulting behaviour.

If your organisation never used the legacy Workbench or those experimental APIs, there’s nothing to do. If it did, inventory the dependencies now, assign an owner to each one and test the replacement before 17 August. Don’t treat the export itself as completion.

There’s a useful lesson in that deadline. Experimental tooling can become production infrastructure long before anyone formally approves it as such. The safest response isn’t to avoid experiments. It’s to keep an inventory, preserve portable artefacts and know what must be retested when a provider removes the interface beneath them.