Database, OS, or Edge: Three Agentic AI Bets From One Week That Reveal an Infrastructure Inflection

Three announcements. One week. One question nobody has answered yet.

Where should AI agents live?

It sounds like an infrastructure detail. It isn’t. The decision about where an agent executes, stores its memory, and accesses data determines everything downstream: how you govern it, how you audit it, what security surface it creates, and how difficult it is to replace or retrain. Oracle answered that question one way on March 24, 2026. Anthropic answered it differently the same week. Neither is wrong. Both choices have consequences.

The Question That’s Now on the Table

Most of the public conversation about agentic AI has focused on what agents can do, the capability story. Summarize documents, execute multi-step tasks, operate autonomously between prompts. The demonstrations are compelling. But enterprise architects evaluating these systems are asking a different question: given that agents need persistent memory, data access, and the ability to take actions with real consequences, where does that infrastructure actually live?

That’s a governance question disguised as an architecture question. And this week, three distinct approaches made themselves visible in the same news cycle.

Oracle’s Bet: Agents Live Where the Data Lives

Oracle’s announcement at Oracle AI World London on March 24, 2026 reflects a specific premise: the cost of routing agent state through an external orchestration layer, in latency, security surface, and governance complexity, is a problem worth solving at the architecture level.

Oracle’s answer is the Unified Memory Core, which Oracle describes as a persistent, governed memory layer for AI agents built directly into the database engine. Agent context lives inside the database. It’s governed by the same enterprise data controls that already apply to everything else in that system. The agent doesn’t call out to an external memory store; it reads and writes within the data environment it’s already authorized to access.

The Oracle AI Database Private Agent Factory extends this logic to agent creation itself: a no-code builder deployable as a container, in public cloud or on-premises, that constructs agents operating within Oracle’s data infrastructure. And the expanded AI Agent Studio for Fusion Applications targets organizations running Oracle ERP, HCM, and supply chain systems, places where the data is already centralized and the governance model already exists.

The architectural premise is coherent. If your data lives in Oracle and your agents need that data, running agents inside the database eliminates a class of integration problem. The trade-off is equally coherent: this approach requires existing Oracle infrastructure investment. It’s not portable. An organization that standardizes on Oracle’s database-native agents is building on Oracle’s stack, with Oracle’s governance model. That may be exactly what enterprise security teams want. It’s also a form of dependency that deserves deliberate evaluation before commitment.

Futurum Research characterized the approach as an attempt to eliminate agent integration complexities. Whether that characterization proves accurate under enterprise workloads, at real scale, with real data, running real multi-step tasks, is a question pilots will answer. No independent benchmark evaluation of Oracle’s agentic capabilities exists at this writing. The announcement is vendor-stated. The architectural logic is sound. The production evidence doesn’t exist yet.

Anthropic’s Bet: Agents Live in the Operating System

Anthropic’s approach to the same question is architecturally opposite. Claude Computer Use, launched as a research preview for Claude Pro and Max subscribers on macOS around March 24–25, 2026, doesn’t put agents inside a data infrastructure. It puts them at the OS layer, with access to whatever applications and data already exist there.

According to reporting from Engadget and PCMag, as summarized in the Daily AI News newsletter, Claude can directly control a user’s browser, mouse, keyboard, and screen. It doesn’t need data centralized in a particular platform. It works with the applications already running on the machine, the way a human assistant would.

The architectural logic here is also coherent. OS-level access means cross-application task execution without requiring organizational data to be centralized anywhere. An agent can move between a browser, a spreadsheet, an email client, and a calendar without the organization needing to standardize its data infrastructure first. The deployment requirement is simpler: a Claude Pro or Max subscription and a Mac.

The trade-off is the security surface. Direct OS access, mouse, keyboard, screen control, is a meaningful elevation of privilege. The questions enterprise security teams will ask are predictable: what does Claude do if it encounters sensitive credentials on screen? What’s the authorization model for which tasks an agent can initiate without a human checkpoint? What’s the audit trail? Research preview status means Anthropic is collecting exactly this kind of information before general availability. These questions aren’t rhetorical criticisms, they’re the standard evaluation framework for any tool that operates at the OS layer.

Anthropic’s official technical documentation for Computer Use was not available at time of publication. The capability is confirmed by T2 journalism (Engadget, VentureBeat) and the Substack newsletter. The governance model details will require the official announcement to assess fully.

The Third Approach: Local-First and On-Device

A third architectural model has been visible in prior cycles’ coverage of local-first agentic AI approaches. The premise differs from both Oracle and Anthropic: agents execute on-device, with no cloud dependency for inference or memory. Data doesn’t leave the device. Governance is enforced by physical containment rather than platform policy.

The trade-off here is capability ceiling. On-device models operate with the compute and memory available on the local machine. That’s improving rapidly, but it remains a different constraint set than cloud-hosted models. The local-first approach trades raw capability for data sovereignty and privacy guarantees that neither database-native nor OS-native cloud approaches can match by default.

For organizations handling sensitive data under strict regulatory requirements, that trade-off may be the right one. For organizations that need the full capability envelope of frontier models, it probably isn’t, yet.

A Framework for Enterprise Evaluators

These three approaches make fundamentally different trade-offs across four dimensions that enterprise evaluators should be mapping explicitly:

This table is editorial synthesis. The rows are grounded in the verified facts from this cycle’s announcements, but the comparison framework itself is TJS’s analysis, not an industry-established standard. Use it as a starting point for your own evaluation, not as a definitive assessment.

What the Race Means, and What It Doesn’t

The agentic AI infrastructure race isn’t primarily about which model is smarter. Oracle’s agents and Anthropic’s Claude are built on different premises for different environments. The “winner” won’t be determined by benchmark scores.

It’ll be determined by governance fit. Which approach maps most cleanly onto the data controls, security requirements, audit obligations, and integration patterns that enterprises already operate under? That’s a question individual organizations have to answer for their own context, not a question the vendors answer for them.

What this week’s announcements confirm is that the architecture question has moved from theoretical to concrete. These are real products with real deployment options. The decision about where your agents live is no longer premature. It’s imminent.

Evaluate carefully. Pilot before committing. And make sure the governance questions get asked before the contracts get signed.