Every AI platform has a portability story. Most of them are marketing. The hard test isn’t “can the customer leave eventually?” — every contract ends. The hard test is “if the customer wanted to migrate off your platform tomorrow, how many days of work is that?”

For most enterprise AI tools shipping in 2026, the honest answer is 90 to 180 days. Your prompts are in the vendor’s UI. Your traces live in their proprietary observability stack. Your auth integration is their identity model. Your data is in their multi-tenant cluster, copied via their ingestion pipeline. Leaving means rebuilding most of the wiring.

Serac was designed with a different number in mind. We wanted “migrate off Serac” to be measured in hours, not months — and to be possible without our help. Here’s where each lock-in point usually lives, and how we addressed it.

Lock-in point 1: the LLM provider

The most common form of AI vendor lock-in in 2025 was the LLM relationship. A platform would integrate with OpenAI, embed the keys in their backend, mark up the inference cost, and pass the bill to the customer. Switching providers meant migrating to a new platform.

Serac is BYO LLM. The customer brings their own credentials for Anthropic, OpenAI, Google Gemini, AWS Bedrock, or Azure OpenAI. Inference cost goes directly to the provider. We do not mark up tokens. We do not resell. We do not aggregate billing.

There’s a self-interested reason for this: we don’t want to be in the inference reselling business. Margins on resold tokens are thin and they shrink every quarter as the underlying models commoditize. But the architectural reason is more important: tying the agent to a specific LLM vendor makes the agent fragile against the next model. The customer who picked us in 2024 with Anthropic credentials should be able to switch to whatever model is best in 2027 without rebuilding their integration.

Concrete: the LLM client in the Serac runtime is a thin adapter over each provider’s official SDK. New providers ship as a new adapter file, ~300 lines, mostly translating between the provider’s tool-calling shape and the Serac internal format. Two of the adapters in the repo are community contributions.

Lock-in point 2: the credential vault

The agent needs ServiceNow credentials, integration tokens (Jira, Azure DevOps, Confluence), and per-tenant configuration. The default vendor pattern is: vendor stores the secrets in their multi-tenant vault, encrypted at rest, single tenant per row.

That pattern has two failures. The first is that the customer’s secrets are now in the vendor’s perimeter, which means a vendor breach is a customer breach. The second is that switching off the vendor means re-uploading every credential elsewhere, which is exactly the kind of work that gets postponed.

Serac supports two credential vault models:

  • Self-hosted Serac: credentials live in whatever you already run. We have a Google Cloud KMS reference integration; the same pattern works for AWS KMS, Azure Key Vault, HashiCorp Vault. The Serac runtime never persists the credential — it fetches at call time and discards. Configure once, never touched by us.
  • Hosted Serac: credentials live in our managed KMS, but the customer holds the key wrap. We can’t decrypt without their participation. If the customer leaves, they revoke the wrap and the vault is dead to us.

Either way, the credential is not the lock-in. The vault interface (Vault.get(key), Vault.put(key, value), Vault.revoke(key)) is the same regardless of which backend you wire in. Swapping vaults is a config change.

Lock-in point 3: data residency

This is the lock-in point most enterprise buyers care about and most vendors handwave. The buyer asks “where does my data live?” The vendor says “in our cloud, we’re SOC 2.” The buyer doesn’t have a clean way to verify, and they certainly can’t move the data.

Serac data residency by deployment mode:

  • Self-host: your perimeter. Your VPC, your subnet, your network policies, your DLP. We don’t see any traffic. The runtime can be air-gapped if your environment requires it; the only outbound dependency is the LLM provider you chose.
  • Hosted EU: Frankfurt (eu-central-1) region only. Data does not leave the EU. Backups stay in the EU. Logs stay in the EU. The CDN is EU-only for tenant traffic. We do not have a US region for tenant data.
  • Hosted EU + sub-processor disclosure: every sub-processor we use (cloud provider, KMS, observability backend) is listed at serac.build/legal/subprocessors. The list is short. Changes are notified 30 days ahead.

The relevant regulatory hook for 2026 is the EU AI Act, which imposes data-residency and traceability obligations on systems deployed in EU jurisdictions for what it classifies as “high-risk AI” — and agentic platforms that touch IT operations data are likely to land in that class. Customers asking us for residency commitments in 2025 were doing it for procurement. Customers asking in 2026 are doing it for the regulator.

Portability matters here because the residency commitment is only meaningful if you can verify it. With self-host, you can. With hosted, you have to trust us — and we shipped the subprocessor list because that’s the verification you should reasonably expect.

Lock-in point 4: observability and traces

A common pattern in vendor lock-in: the agent emits beautiful structured traces, but the traces are stored in the vendor’s proprietary observability system. You can view them in their dashboard. You cannot export them in a useful format. When you migrate, you lose the historical record.

Serac emits OpenTelemetry. Every agent run produces standard OTel traces with spans for plan, classify, review, execute, summarize. Spans carry attributes for tool name, scope, target table, approval status, latency. You point the OTLP exporter at whatever observability backend you run — Datadog, Honeycomb, Grafana Tempo, AWS X-Ray, your own ClickHouse. We don’t ship a “Serac observability dashboard” as the primary interface. We ship traces to your stack.

We also emit the planner’s prompts and the LLM responses to the trace, with PII redaction configurable at the runtime level. If you want to audit every agent decision, you don’t ask us for an export — you query your own observability platform.

The Serac dashboard does have a built-in trace viewer for convenience, but it reads the same OTel format you can read elsewhere. There’s nothing in the dashboard you can’t reconstruct from the OTel stream.

Lock-in point 5: configuration

Agent configuration is a sneaky lock-in vector. Some platforms put config in a proprietary CMS — you click through the UI to set up agents, tools, policies, integrations. Migrating means re-clicking through the UI of the next platform.

Serac configuration is file-based. Agent definitions, tool registrations, approval policies, integration credentials, scope mappings — all .yaml and .ts files in your repository. Version-controlled. Diff-able. Migrable by copy-paste.

We do have a web UI for editing config, but the UI writes to the same files. The files are the source of truth. If you want to script your config from CI, you commit a file. If you want to migrate, you take the files.

This is the kind of choice that looks pointlessly opinionated until you’ve migrated off a SaaS that hid your config in their database, at which point it’s the only choice you would ever make again.

Lock-in point 6: identity and auth

The customer’s existing IdP — Okta, Azure AD, Google Workspace — needs to authenticate the operators using Serac. Many AI platforms add their own user database, sync via SCIM, and over time become the IdP for their slice of your stack. That’s lock-in by inertia: you’ve onboarded ten people through their UI, you’ve configured ten role-based access policies in their model, now leaving means redoing all of that.

Serac defers to your IdP. SAML, OIDC, or service-account passthrough. We don’t store user records. We don’t issue our own credentials. Role-based access policies are declared in the same config files mentioned above — leaving means handing those policies to whatever you migrate to, and they’ll be readable YAML, not a vendor-proprietary export.

What is NOT portable yet

The honest part: there’s one piece of Serac that isn’t portable, and we know it.

The activity tracking schema — the format Serac uses to record agent runs, decisions, and outcomes — is currently ours. There’s no open spec for it. If you self-host Serac and accumulate two years of activity history, then decide to migrate to a different agent platform, you can export the data (it’s stored in your Postgres, you own it), but the schema is undocumented and the next platform won’t natively understand it.

We’re shipping the v1.1 schema spec in the second half of 2026, with a normalized format and a migration tool. Until then, this is the one lock-in point we haven’t closed.

We mention it because the alternative — pretending we’ve solved a problem we haven’t — is exactly the vendor behavior we said we wouldn’t replicate.

The pattern

Portability is what you design in at the start. You can’t bolt it on. Every lock-in point we describe above corresponds to a specific architectural decision that had to be made before we wrote a single line of customer-facing code. BYO LLM means the inference client is an adapter. BYO vault means the secrets interface is an interface. File-based config means there’s no admin UI database. OTel means there’s no Serac observability schema.

The lock-in points you didn’t design against will quietly assemble themselves while you’re not looking. By the time you notice, your customers have years of data trapped inside conventions you can’t unwind.

We picked the slower architecture on purpose. The trade is: harder to build, easier to leave. We think that’s the right ratio for software that lives in the most consequential systems your developers touch.