Agentic AI , AI Strategy , Software development Jul 24, 2026

Presence, Managed Projects, and the Quiet Shift in How Vendors Want to Own Your Agent Layer

VECTOR Labs Team

Last updated on: Jul 24, 2026

OpenAI's Presence and Anthropic's Claude Managed Projects represent something more consequential than feature releases. Both products extend vendor control from the model layer into the orchestration layer, and engineering leaders who treat them as productivity upgrades rather than infrastructure ownership plays are making a strategic error that will be difficult to reverse once workloads scale.

The Architecture of the Move

The pattern is consistent across both vendors. Presence gives OpenAI persistent memory, scheduled task execution, and proactive agent behaviour housed inside OpenAI's infrastructure. Managed Projects gives Anthropic a structured context layer that persists across sessions and organises agent behaviour around project-scoped memory. In both cases, the vendor is no longer just providing a model. The vendor is providing the state management, the scheduling runtime, and increasingly the orchestration logic that sits between your application and the underlying model.

This matters because durable state is where enterprise value accumulates. When agent memory, task history, and workflow context live on a vendor's infrastructure rather than your own, the relationship between your organisation and that vendor changes. Migrating a model is a technical task. Migrating accumulated agent state, embedded workflows, and project-scoped context is an operational project with real cost and risk.

The commercial logic for the vendors is straightforward. A customer whose agents are stateless and model-agnostic can switch providers in days. A customer whose agent layer is entangled with vendor-managed memory and scheduled autonomy faces months of migration work and meaningful operational disruption.

What Persistent Memory and Scheduled Autonomy Actually Commit You To

Persistent Memory as Switching Cost

Persistent memory in agent systems is not a convenience feature. It is the accumulation of context that makes agents useful over time. When that memory is managed by the vendor, the operational value of the system becomes inseparable from the vendor's infrastructure.

The practical implication is that the longer an agent operates with vendor-managed memory, the more expensive it becomes to move. This is not a hypothetical concern. It is the same dynamic that made early SaaS CRM migrations painful once customer data, workflow history, and integration logic had accumulated inside a single platform.

Scheduled Autonomy and Runtime Dependency

Scheduled autonomy, the ability for agents to initiate tasks without a human trigger, introduces a runtime dependency that is qualitatively different from API call patterns. When an agent is scheduled to execute on a vendor's infrastructure, your operational continuity is now a function of that vendor's uptime, policy decisions, and pricing changes.

This is not an argument against scheduled agents. It is an argument for knowing precisely where the scheduling runtime lives and what your fallback posture is if that runtime changes behaviour, pricing, or availability.

Pricing Opacity and the Scaling Problem

Neither Presence nor Managed Projects has disclosed pricing at a level that allows enterprise buyers to model costs at scale. This is not unusual for early-stage products, but it is a meaningful risk for organisations making infrastructure commitments.

Agent workloads have a compounding cost structure that differs from standard API usage. Persistent memory retrieval, scheduled task execution, and multi-step orchestration all generate inference calls that are not always visible in headline pricing. Organisations that evaluate these platforms at pilot scale and commit to production deployment without modelling the full cost surface frequently encounter budget overruns once agent activity reaches production volumes.

Companion piece to our broader work on production agent deployments. See Why Most Enterprise AI Agent Projects Never Leave the Pilot Stage for the governance and cost modelling decisions that separate pilots from production systems.

The absence of disclosed pricing also limits your ability to negotiate. Vendors who disclose pricing after a customer has committed to a platform architecture have a structural negotiating advantage. Signing deployment agreements before pricing is transparent is a procurement risk, not a technical one.

What CTOs Should Demand Before Signing

The due diligence questions for these platforms are different from standard model API evaluations. The relevant questions are architectural and contractual, not benchmark-oriented.

On data portability, the requirement is explicit: any deployment agreement should specify the format, completeness, and latency of agent state export. If the vendor cannot commit to a documented export mechanism for persistent memory and project context, the switching cost is effectively infinite.

On cost transparency, demand a detailed breakdown of what generates inference calls within the orchestration layer, not just at the model level. Scheduled task execution, memory retrieval, and tool call routing all carry cost. Agreements that price only at the model layer obscure the true operational cost.

On SLA scope, clarify whether uptime commitments cover the orchestration runtime, not just model availability. An agent that cannot execute scheduled tasks because the scheduling infrastructure is degraded is unavailable from a business perspective, even if the underlying model is responding normally.

The Vendor Relationship You Are Actually Entering

The frame that best describes what Presence and Managed Projects represent is platform consolidation, not feature expansion. Both products are designed to make the vendor the durable layer in your agent architecture, with your application logic sitting above and your model access sitting below.

This is a legitimate business model. Platform consolidation is how enterprise software markets mature, and there are genuine operational benefits to having orchestration, memory, and scheduling managed by a single provider. The risk is not in using these products. The risk is in committing to them without understanding the architecture of the dependency you are accepting.

Engineering leaders who evaluate these platforms on capability alone and defer the portability and cost questions will find those questions harder to answer once the platform is load-bearing. The time to negotiate data portability, pricing transparency, and SLA scope is before the agent layer is in production, not after.

Where Vector Labs Fits

We help engineering teams design agent architectures that preserve portability and model the true cost surface before vendor commitments are made. Our work on production agent deployments, documented in Why Most Enterprise AI Agent Projects Never Leave the Pilot Stage, addresses the governance and infrastructure decisions that determine whether agent systems remain operationally flexible at scale. If you are evaluating platform commitments for agent deployment, speak to our team at vector-labs.ai/contacts.

FAQs

What specifically makes Presence and Managed Projects different from standard model API access?

Both products move vendor control beyond the model into the orchestration layer. Standard API access gives you a model endpoint that your infrastructure calls. Presence and Managed Projects add persistent memory, project-scoped context, and scheduled task execution managed on the vendor's infrastructure. The distinction matters because your application's operational state now lives inside the vendor's platform, not your own systems.

How should we assess the portability risk before committing to one of these platforms?

The core test is whether the vendor can provide a documented, complete export of agent state, memory, and project context in a format your team can ingest into an alternative system. If that export mechanism does not exist or is not contractually guaranteed, the switching cost is undefined and likely high. Treat the absence of a portability commitment as a material risk, not a minor contractual gap.

How do we model costs when pricing has not been disclosed?

Request a detailed breakdown of every operation within the orchestration layer that generates an inference call or a billable event. This includes memory retrieval, tool call routing, scheduled task initiation, and context window usage per agent turn. Build a cost model at three times your expected production volume before committing, because agent workloads tend to scale non-linearly as use cases broaden. If the vendor will not provide this breakdown, that itself is a signal about the cost structure you are accepting.

Are there architectural patterns that reduce dependency on vendor-managed orchestration?

Yes. Keeping state management in your own infrastructure, using vendor platforms for model access only, and building orchestration logic in frameworks you control are all approaches that preserve portability. Open-source orchestration frameworks give you a layer of abstraction between your application and the underlying model provider. The trade-off is that you carry more operational responsibility for the orchestration runtime, which requires engineering capacity to maintain.

What SLA terms should we require for agent platforms with scheduled autonomy?

Standard model availability SLAs are insufficient when agents are executing scheduled tasks. You need uptime commitments that cover the scheduling runtime and the memory retrieval layer, not just the model endpoint. You should also define what constitutes a service failure from a business perspective, which is typically a missed scheduled execution or a memory retrieval failure, and ensure the SLA covers those events with measurable remedies.

Is there a scenario where committing to vendor-managed orchestration is the right decision?

Yes. Organisations with limited ML infrastructure capability and a clear, bounded use case may find the operational simplicity of vendor-managed orchestration worth the portability trade-off. The decision becomes more defensible when the use case is unlikely to migrate, the vendor relationship is stable, and pricing is transparent enough to model at scale. The risk profile is highest when the use case is likely to expand, when pricing is opaque, and when the vendor's platform strategy is still evolving rapidly.

A team that understands you

With 20+ years of experience in the world's leading consultancy companies, implementing AI and ML projects in industry-specific contexts, we are ready to hear your challenges.

Talk with an AI expert