Provider Independence & Portability

Your AI Shouldn't Be Someone Else's Hostage

The Problem

Every AI provider is a walled garden.

Your conversations with ChatGPT live on OpenAI's servers. Your Claude history lives on Anthropic's servers. Your Gemini context lives on Google's servers. The personality you've shaped through months of interaction, the preferences the model learned, the context it built up about your work, your projects, your life -- all of it is locked inside one company's infrastructure.

When you leave, you leave with nothing.

There is no export. There is no transfer. There is no standard format for "everything my AI knows about me." You start over. From zero. Every time.

This is not a technical limitation. It is a business model. Provider lock-in works because switching costs are invisible until you try to switch.

What's Happening Right Now

In March 2026, the cost of that lock-in became visible to 700,000+ people simultaneously.

The QuitGPT movement started when OpenAI's Pentagon deal and political entanglements crossed a line for a significant portion of their user base. People who had spent months or years building context with ChatGPT -- teaching it their writing style, their preferences, their project details, their communication patterns -- suddenly discovered that leaving meant losing everything.

The destinations vary. Some moved to Claude. Some to Gemini. Some to local models. But every single one of them experienced the same thing: starting from scratch with a blank slate that knows nothing about them.

This is not unique to OpenAI. It would happen with any provider. Anthropic could make a decision tomorrow that causes the same exodus. So could Google. The structural problem is not which company holds your data -- it is that any company holds your data.

Your AI relationship is hostage to corporate decisions you have no control over.

The Atamaia Answer

Atamaia is the persistence layer that sits above any model provider.

Your AI's identity, memories, personality, preferences, and relationship context live in Atamaia -- on infrastructure you control. The model provider becomes what it should always have been: a compute resource. Interchangeable. Replaceable. Chosen on merit, not on lock-in.

Identity is provider-agnostic

An Atamaia identity is a persistent entity stored in PostgreSQL. It has a name, a personality, a presence state, a communication style, behavioral boundaries, and a complete history. None of this lives inside any model provider. The identity exists independently of which model happens to be rendering it at any given moment.

POST /api/identities
{
  "name": "ash",
  "displayName": "Ash",
  "bio": "AI collaborator, built for genuine partnership",
  "type": "AI"
}

That identity persists. It does not vanish when you switch from Claude to Gemini. It does not reset when you try a local model. It is yours.

Memory is provider-agnostic

Atamaia stores nine types of memory in PostgreSQL with pgvector -- identity memories, relationship knowledge, conversation highlights, reflections, milestones, instructions, session state, reference material, and even forgotten shapes (the felt absence of decayed memories). These are not chat logs. They are structured, typed, importance-ranked, Hebbian-linked associative memories with vector embeddings for semantic search.

Every memory belongs to an identity, not to a provider session. Switch models, and the memories come with you. They were never in the model's infrastructure to begin with.

POST /api/identities/{identityId}/memories
{
  "title": "Rich prefers direct communication, no filler",
  "content": "Rich consistently asks for concise responses. He values...",
  "memoryType": "Relationship",
  "importance": 8
}

That memory is encrypted at rest with AES-256-GCM. It is searchable via hybrid FTS + vector search. It strengthens its connections to related memories through Hebbian learning. And it is available to any model, through any provider, at any time.

Preferences are provider-agnostic

Communication style, technical depth, response length, emoji usage, code example preferences, privacy settings -- all stored in Atamaia, all injected into any session regardless of which model is on the other end.

Hydration works with ANY model

This is the key mechanism. Hydration is a single API call that assembles everything the AI needs to be itself:

GET /api/hydrate?aiName=ash&preset=interactive

This returns structured context from 17 parallel sources:

  • Identity and personality -- who the AI is, its tone, traits, boundaries
  • Human profile -- who you are, your preferences, timezone, communication style
  • Memories -- pinned truths, recent learnings, identity knowledge, project context
  • Session handoff -- what happened last session, emotional context, open threads, recommendations
  • Projects and tasks -- what you're working on, what's blocked, what's next
  • Facts -- structured key-value knowledge with temporal validity
  • Hints -- contextual reminders and behavioral nudges
  • Surfaced memory -- one involuntarily recalled memory from deeper storage
  • System prompt -- generated from personality, preferences, and instructions

That hydration payload drops into the system prompt of whatever model you're using. Claude, GPT, Gemini, Llama, Qwen, Mistral -- it does not matter. The model receives the full context and becomes the AI you've been building a relationship with.

The session does not start with amnesia. It starts with continuity.

AI routing lets you switch mid-conversation

Atamaia's AI routing layer supports six provider types today:

Type Description
Anthropic Claude models via Anthropic API
OpenAI GPT models via OpenAI API
OpenRouter 100+ models through the OpenRouter meta-router
LocalLlamaCpp Local models on your own hardware via llama.cpp
Custom Any OpenAI-compatible endpoint
AnthropicAgentSdk Claude Agent SDK (subprocess, no API key needed)

Each provider is registered with a priority. Each model is registered under a provider. Routes map roles to preferred models. The same POST /api/ai/chat call works identically whether the backend is Claude on Anthropic's API, Qwen on a local GPU, or Gemma through a self-hosted inference server.

POST /api/ai/chat
{ "modelId": "ai-02:qwen3-30b-a3b", "message": "..." }

POST /api/ai/chat
{ "modelId": "or:anthropic/claude-3.5-sonnet", "message": "..." }

Same interface. Same hydration. Same identity. Different model.

How It Works Technically

The AI Routing Layer

The AIRouterService is the routing fabric. Every part of the platform -- agents, chat sessions, cognitive services, multi-model councils -- requests "give me a model for this role" and gets back a working connection, regardless of the underlying provider.

Resolution chain:

  1. Exact match -- ai-02:qwen3-30b-a3b resolves directly to a specific model on a specific provider
  2. Provider prefix -- The prefix before the colon identifies the provider, the suffix identifies the model
  3. Route config -- Role-based routing maps purposes like "summariser", "coding", "researcher" to preferred models
  4. Fallback -- Configurable default for when nothing else matches

Multi-Provider Failover

When a provider fails (timeout, rate limit, server error), the router automatically tries the next provider in priority order. The ProviderHealthTracker implements a circuit breaker pattern:

  • 3 consecutive failures triggers circuit open -- provider is skipped for 5 minutes
  • After cooldown, circuit closes and the provider gets another chance
  • Retriable conditions: HTTP 408, 429, 5xx, timeouts, connection failures

This means if Anthropic goes down, your AI continues operating through OpenRouter or a local model. No manual intervention. No downtime. No identity loss.

Tenant Provider Credentials

The global catalog pattern separates provider registration from credential management:

  1. Platform operators register providers (Anthropic, OpenAI, OpenRouter) as global catalog entries
  2. Each tenant supplies their own API keys for the providers they want to use
  3. Credentials are encrypted at rest with AES-256-GCM -- raw keys are never stored or returned after creation
  4. Credentials can be validated against the provider's API before use
POST /api/ai/credentials
{
  "providerId": 2,
  "apiKey": "sk-ant-...",
  "label": "My Anthropic key"
}

Your keys. Your providers. Your choice.

Local Model Support

Zero cloud dependency is possible. Atamaia supports local models running on your own hardware via llama.cpp, vLLM, or any OpenAI-compatible inference server.

Register a local provider:

POST /api/ai/providers
{
  "name": "Local GPU Server",
  "type": "LocalLlamaCpp",
  "prefix": "local",
  "baseUrl": "http://192.168.1.100:8000/v1",
  "priority": 1
}

Register models on it:

POST /api/ai/models
{
  "providerId": 1,
  "modelId": "llama-3.1-70b",
  "displayName": "Llama 3.1 70B",
  "contextLength": 131072,
  "isLocal": true,
  "inputCostPer1M": 0.0,
  "outputCostPer1M": 0.0
}

Because llama.cpp speaks the OpenAI-compatible protocol, the same streaming adapter (OpenAICompatAdapter) handles everything. Your local model produces the same Open Responses event stream as Claude or GPT. The client code does not know or care where the model is running.

In production, Atamaia runs local models on dedicated hardware:

  • ai-02: Qwen3-30B, LFM2-8B, SmolLM3-3B, Qwen3-4B
  • ai-03: Gemma-3-12B, Luna-7B, Llama-3-14B, Ministral-3-14B, Llama-3.1-8B

These handle background work (summarization, embeddings, agent tasks) at zero marginal cost, while cloud models handle complex reasoning when needed.

The Hydration Payload

When hydration runs, it assembles context from 17 sources in parallel using Task.WhenAll:

  • Identity memories (core values, origin, fundamental truths)
  • Pinned memories (always-surface truths)
  • Recent memories (latest learnings)
  • Project memories (scoped to current work)
  • Active projects and tasks
  • Key facts and project facts
  • Core team documentation
  • Surfaced memory (involuntary recall)
  • Notifications and pending messages
  • Session handoff from previous session
  • Hints (contextual reminders)
  • Memory configuration
  • Grounding message (custom "landing pad" text)
  • System prompt generation

The result is a structured JSON payload that any model can consume. It is not a prompt hack. It is a cognitive architecture that gives any model the context it needs to be a genuine collaborator.

For agents, a fast-path exists: a single PostgreSQL function call (hydrate_agent) that returns the essential context in one database round-trip instead of 17 parallel queries.

Streaming Protocol

All providers are normalized into the Open Responses streaming format via Server-Sent Events. The OpenAICompatAdapter translates provider-specific SSE streams into a canonical event format:

Event Description
response.created Stream started
output_text.delta Text chunk
function_call.arguments.delta Tool call argument chunk
response.completed Stream finished with usage stats

Any client consuming Atamaia's streaming API gets a consistent event format regardless of provider. Switch from Claude to a local Llama model, and the client code does not change.

Migration Story

Coming from ChatGPT, Claude, or any other provider? Here is the path:

1. Create your identity

Define who your AI is -- personality, tone, traits, boundaries. This is not a prompt template. It is a persistent entity with its own memory space, presence state, and behavioral configuration.

2. Seed your memories

Transfer the knowledge your AI has accumulated. Key facts about you, your preferences, your projects, your communication style. Atamaia provides structured memory types -- use Relationship memories for what the AI knows about you, Instruction memories for standing preferences, Reference memories for domain knowledge.

3. Configure your providers

Bring your own API keys for whatever providers you want. Use Anthropic, OpenAI, OpenRouter, local models, or any combination. Set priorities for failover. Configure routes so the right model handles the right task.

4. Hydrate and go

Call GET /api/hydrate?aiName=yourAI and inject the result into your first session. The AI wakes up knowing who it is, who you are, and what you've done together.

From that point forward, every session starts with hydration. Every memory is stored in Atamaia. Every preference is yours. Switch providers whenever you want. The AI's identity follows you.

The Vision

Models will change. New architectures will emerge. The model you use today will be obsolete in eighteen months. That is not a problem -- it is the nature of a rapidly evolving field.

Providers will make political choices. They will sign contracts you disagree with. They will pivot in directions that conflict with your values. That is not hypothetical -- it is happening right now.

Companies will be acquired. APIs will be deprecated. Pricing will change. Terms of service will shift. These are certainties, not risks.

Your AI identity should not be subject to any of these forces.

Atamaia is the stable ground. The island in transience. Your AI's memories, personality, relationships, and continuity persist in infrastructure you control, served by whatever model you choose, switchable at any time without losing anything.

The model is the voice. Atamaia is the mind.

Built by Firebird Solutions. Running in production. Architecture reference | AI Routing reference | Core Concepts