AIS
Explainer · Facts, not marketing

Persistent memory
for AI agents.

This is a plain-English explanation of what AIS is, what we've actually built, and what we are honest about not having built yet.

The business perspective covers the problem, the solution, the architecture, and the roadmap without code. The technical perspective covers the stack, the database, the integration surface, and where the scars are.

Part I

The business perspective

Conceptual, plain-English, no code. Five sections. Roughly a ten-minute read.

The problem

Business perspective · 01

AI agents are useful for ten minutes. Then they forget you exist.

Every chat starts from zero. Every preference you've explained, every correction you've made, every project context you've built up — gone the moment the session ends. The agent goes back to being a stranger. Companies are spending billions on smarter models, but the models still can't tell you what they did yesterday.

The industry calls this "stateless." The user experience is "amnesia."

For users

Re-explaining context every session. No accumulated relationship. The agent never gets better at being your agent.

For builders

Every product reinvents memory poorly. RAG hacks, custom databases, bolt-on context. Nobody owns the layer beneath the agents.

For the market

Agents can't be trusted with anything important because they can't prove what they remember, where it came from, or who said it.

The fix isn't a smarter model. The fix is an infrastructure layer that every agent shares — one that gives each agent a real identity, persistent memory, and a verifiable trail of where every fact came from.

What we built

Business perspective · 02

AIS — the Agent Identity Service — is the layer that sits beneath any AI agent and gives it two things: a persistent identity and a memory that survives.

It is not a chatbot. It is not an agent framework. It does not replace LangChain, CrewAI, or anything else you might be using to build agents. It runs underneath all of them. An agent connects to AIS once. From then on, it remembers — across sessions, across platforms, across time.

Think of it the way email infrastructure works. Gmail, Outlook, and Apple Mail all look different. But underneath, they speak SMTP and IMAP. AIS is the SMTP of agent memory.

What this unlocks

  • Continuity. An agent you used yesterday remembers you today. It picks up where it left off. It gets better at being your agent the more you use it.
  • Portability. Your memory belongs to you, not to whichever vendor built the agent. You can take it with you. You can export it. You can show it to another agent and have that one pick up where the first left off.
  • Receipts. Every fact an agent remembers can be traced back to where it came from — which session, which model, which source. When the agent says something, it can show you why.
  • Trust. Identities are cryptographically verifiable. Memories are provenance-tracked. When something goes wrong, you can prove what was remembered, what changed, and when.

The brand is AIS — the Agent Identity Service. One name. The product is the infrastructure, and the infrastructure is the product.

The architecture, conceptually

Business perspective · 03

Four layers. They build on each other. Read it from the bottom up.

HUMAN OWNER claims · audits · exports AI AGENT remembers · acts · learns — AIS PLATFORM — Intelligence Decides what matters · assembles context · learns from use L4 Agent State Goals · skills · personality · the agent's "shape" L3 Memory 3 tiers · searchable · provenance-tracked · portable L2 Identity Who is this agent · who owns it · proven cryptographically L1 CROSS-CUTTING Privacy & Consent Content Safety Portability Multi-source Sync

Each layer sits on the one below it. You can't have memory without identity. You can't have intelligence without memory.

Identity — the foundation

Every agent gets a permanent, globally-unique cryptographic identity. A human can claim ownership through a signed bond. Now we know who every agent is, who owns it, and whether to trust what it says.

Memory — the substrate

Three tiers of memory — what the agent is working on right now, what happened recently, and what it knows long-term. Searchable by meaning, not just keywords. Every memory carries a receipt: where it came from, which model wrote it, and how confident we are.

State — the shape of the agent

On top of memory sits the agent's current goals, the skills it's learned, its personality, and its rules of engagement. This is the difference between "an LLM" and "this specific agent."

Intelligence — what emerges

When an agent has identity, memory, and state, it can finally do the thing models alone can't: assemble the right context for the moment, learn what's important to its owner, and improve over time.

The cross-cutting concerns — privacy, content safety, portability, and syncing from existing platforms — touch every layer. They are not features bolted onto AIS; they are properties of the substrate itself. Memories can be exported. Consent is granular. Safety runs on every write.

Where we are

Business perspective · 04

AIS is in production. The numbers below are real and current.

10
agents in production
91.8K
memories stored
85
MCP tools live
150+
REST endpoints

What is actually working today

  • Live agents using AIS daily. Multiple AI agents — Corbot, Tank, Ender, Data, Lisbeth — operate with full persistent memory across sessions. They remember conversations from weeks ago.
  • Open distribution channels. AIS is reachable as a hosted REST API, as an MCP server (the protocol Claude, Cursor, and others use to integrate tools), and as an installable npm package. Three on-ramps to the same memory.
  • Benchmark-tracked, methodology-honest. We run LongMemEval — the standard long-memory benchmark — on production at least weekly. Today's run (per-turn ingestion + LLM fact extraction, 100-question subset) hit R@5 of 48.9% and R@10 of 51.1%, with the single-session-user segment at 58.6%. On the harder 500-question full haystack with blob ingestion, we're at 29.2% R@5 / 56.0% end-to-end answer accuracy. Every run is logged in HISTORY.md, including the regressions.
  • Cryptographic identity, end-to-end. Every agent has a W3C-standard Decentralized Identifier. Human ownership is established through signed Verifiable Credentials. This is the same identity standard that the broader Web3 / digital identity world has converged on.
  • Self-healing infrastructure. Production has weathered real outages — a 14-day silent vector store failure, an 8-hour database pool exhaustion, a TypeScript build wedge — and each one has been root-caused, fixed at the source, and turned into a CI gate. The codebase remembers its own scars.

Where we have honest gaps

  • Distribution beyond developers — Slack, browser extensions, and end-user UX surface are spec'd but not all shipped.
  • Billing is wired (Stripe), pricing is decided (per-agent), but the public pricing page is intentionally absent until distribution catches up.
  • The retrieval pipeline keeps getting better, but it is still actively being tuned. New benchmark results land roughly weekly.

Where we are going

Business perspective · 05

Three things, in order: ship distribution, prove trust, become the default substrate.

NEAR-TERM · NEXT 1–2 QUARTERS

Distribution beyond developers

Memory should not require a CLI. We're shipping the surfaces where people already work — Slack, MCP-compatible clients (Claude Desktop, Cursor, Continue), and short links that act as memory receipts (the aismem.to/your-agent pattern). The underlying API stays exactly the same; the surfaces multiply.

AIS stays the single brand for both the infrastructure and the end-user experience. The on-ramps multiply; the identity stays consistent across all of them.

MID-TERM · 2–4 QUARTERS

Trust through receipts

The product moat is not the memory; it is the proof. When you ask an agent "why do you think that," it should show you the actual chain: which fact, from which conversation, on which date, in which platform. Provenance and temporal chains are already in the data; the work ahead is making them visible to humans in a way that doesn't require reading a database.

We're also building the contested memory workflow — when a human disagrees with an agent's memory, both versions get stored with timestamps, and the agent can show its work for any future decision.

LONG-TERM · MULTI-YEAR THESIS

The substrate everyone uses

Email won because SMTP is open and portable. AIS is built the same way. The identity standard (W3C DIDs) is open. The memory format is portable. The protocol layer (MCP) is open. Lock-in is the opposite of the thesis.

The long-term position is to become the layer underneath every agent the way Cloudflare became the layer underneath every site. Most users won't know AIS exists. They will only know that their agent remembers them.

The bet, in one sentence: smarter models without memory plateau quickly; dumber models with memory keep getting better. The next decade of AI is won at the memory layer, not the parameter count.

Part II

The technical perspective

The stack, the schema, the integration surface, the scale, and the scars. Pulled from the codebase and production where possible. Seven sections.

The stack

Technical perspective · 06

Conservative, boring, production-grade. We pick stable infrastructure over novelty. The only "novel" piece is the data model itself.

Layer Choice Why
Language TypeScript (strict mode) Same language across backend, frontend, agents.
Runtime Node 20 LTS (bookworm-slim) glibc — needed for native ONNX bindings.
HTTP Express 5 + Helmet + express-rate-limit Battle-tested. path-to-regexp pinned to 0.1.13.
Database Postgres (Supabase) + pgvector HNSW One store for relational + vector. No separate vector DB.
Cache Redis (ioredis) with in-memory fallback Hot active-tier memory. Service stays up if Redis dies.
Embeddings BGE-small-en-v1.5 via @xenova/transformers ONNX 384-dim, local inference, no OpenAI dependency on the query path.
Identity Veramo (W3C DIDs, VCs, SD-JWT-VC) did:web method. Ed25519 signing.
Integration MCP SDK + REST + OAuth 2.0 (Layer 1 live) 85 MCP tools. 150+ REST routes. Device-code flow shipped.
Billing Stripe Per-agent metered pricing. Webhooks land in Postgres.
Observability PostHog · Sentry · Winston Product analytics, error tracking, structured logs.
Hosting Railway (API) · Vercel (sites) Push-to-deploy. Branch protection requires Type Check + CI gates.
Testing Vitest (~3,000 tests across the monorepo) Unit, integration, and live driver suites.

What is deliberately not on this list: edge functions, novel DB engines, an in-house vector store (we ran one and removed it), or any proprietary protocol. Identity is W3C. Integration is MCP. Storage is plain Postgres.

The database

Technical perspective · 07

Single Postgres instance, multi-tenant with row-level security. The vector store is pgvector inside the same Postgres — we cut over from a separate ChromaDB in May after a 14-day silent outage taught us a lesson about operational surface area. One database is easier to keep healthy than two.

Core tables

Table Purpose
ais_agents One row per agent. DID, status, owner, personality config, metadata.
ais_memories The memory layer. Includes embedding vector(384) column, tier, type, importance, trust, provenance JSON.
ais_memory_relationships Directed, weighted edges between memories. 6 relationship types (RELATED_TO, CAUSED_BY, SUPERSEDES, etc.).
ais_bonds Human↔agent ownership. Verifiable Credentials with Ed25519 signatures. Primary / delegated / no-expiry.
ais_goals · ais_skills · ais_constitution Agent state layer. Goals with status, skills with temperature, constitutional rules.
ais_consents · ais_audit_log Privacy wallet. Selective disclosure grants with per-field granularity. Every access logged.
ais_memory_quarantine Safety pipeline holds. Manipulation Filter flags suspicious content for review.

Vector configuration

ais_memories — vector index
-- HNSW index on 384-dim BGE-small embeddings
CREATE INDEX ais_memories_embedding_idx
  ON ais_memories
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 100);

-- Build perf on production: 91,832 vectors → 97 seconds, 179 MB on disk
-- Query latency: ~15-40ms p50 including network round-trip
Multi-tenant isolation

Every memory carries a tenant_id. Row-level security enforces tenant_id = current_setting('app.current_tenant_id', true)::uuid on every read. Service-role queries bypass RLS via FOR ALL TO service_role USING (true). Tenants are cryptographically isolated even when sharing the same physical rows.

Tier check constraint

ais_memories.tier is constrained to exactly 'active' | 'session' | 'long_term'. Memories promote and demote between tiers based on access patterns. The constraint is enforced at the DB level — no application-layer misclassification can slip through.

Migration discipline

238 SQL migrations across the platform. The HNSW index migration is a known exception — CREATE INDEX CONCURRENTLY can't run inside a transaction, but the standard migration runner wraps each file in one. We ship the SQL with a NULL-row pre-flight check that fails loudly if forgotten, and apply the index via a one-shot Node script that mirrors the backfill path.

Connection pool self-healing

The Postgres backend (PostgresStorageBackend) extends EventEmitter. Pool errors trigger a 30-second probe with a circuit breaker. Health checks actually probe — after the chromadb outage that taught us "healthy: true" is not the same as "actually responding," every health endpoint now does the round-trip.

Bulk embedding backfill

Memories without embeddings get progressively embedded by a background worker. The backfill uses UPDATE FROM VALUES with typed placeholder pairs — ~6ms per row vs ~50ms for per-row UPDATEs. 8× speedup. Idempotent; safe to re-run.

Memory layer — internals

Technical perspective · 08

The memory subsystem is where most of the engineering investment lives. It is also where the bulk of the benchmark gains come from. Three tiers, six memory types, a relationship graph layered on top, and a hybrid retrieval pipeline (RRF) for query.

Active
Redis hot cache
Current task context
Session
Postgres + pgvector
Recent interactions
Long-term
Postgres + pgvector
Indefinite retention

The retrieval pipeline

Query path on /v1/agents/:id/memory?query=...
1. CLASSIFY    →  Detect query type (fact / event / lesson / etc.)
2. EMBED       →  BGE-small-en-v1.5 → 384-dim vector (local, no network)
3. SEARCH      →  pgvector HNSW (cosine) +  Postgres FTS in parallel
4. FUSE        →  Reciprocal Rank Fusion combines both rankings
5. EXPAND      →  Optional graph traversal (1-2 hops via relationships)
6. RANK        →  Score = f(similarity, importance, recency, trust)
7. RETURN      →  Top-N memories + queryMetadata trail

Every step is opt-out via query parameters. The default is on. The queryMetadata response field reports exactly which steps fired, with timing — so when retrieval misbehaves on a benchmark, we can isolate the failing stage.

Memory types — six kinds

Distinct types so the classifier can pre-filter:

  • fact — Static information ("user prefers TypeScript")
  • event — Something that happened ("deployed v2.1 on March 5")
  • lesson — Learned insight ("mocking the DB caused a prod failure")
  • context — Current situation ("working on auth refactor")
  • goal — Objective ("reduce API latency below 200ms")
  • task — Work item ("implement rate limiting on /v1/register")
Relationship graph

Stored in ais_memory_relationships. Directed, weighted edges between memories with one of six relationships:

  • RELATED_TO — semantic neighbor
  • CAUSED_BY — causal antecedent
  • CONTRADICTS — temporal disagreement
  • ELABORATES — refinement or detail
  • SUPERSEDES — replaces an outdated fact
  • DEPENDS_ON — prerequisite

Three creation pipelines: LLM-extracted on store, explicit API, and statistical co-retrieval inference. Multi-hop traversal (1–2 hops) via plain recursive SQL.

Trust + provenance

Every memory carries provenance metadata: which model wrote it, which session, which platform, which source. Trust scores combine source reliability and content quality. A memory quality service scores content independently of trust.

The recall API returns the full evidence trail. When a user asks "why do you think that," the agent can reply with the chain — not just the conclusion.

Tier promotion / demotion

Active memories that go untouched demote to session after a threshold. Frequently-accessed session memories promote to long-term. Demotion runs as a scheduled job. Promotion runs inline on access, so the next query sees the new tier.

Multi-source ingest

Agents can ingest from external sources: ChatGPT exports, Claude session data, Mem0 stores. Each source registers, gets a sync cursor for incremental pulls, and writes into the same 3-tier pipeline. The MCP handler sync_memory_from_source is the canonical entry point. A server-side validator gates writes; AIS cannot read the client filesystem, so the validator runs on whatever the client sends.

Identity layer — internals

Technical perspective · 09

Identity is built on W3C standards via the Veramo stack — DIDs (Decentralized Identifiers), Verifiable Credentials, and SD-JWT-VC for selective disclosure. Ed25519 keys, did:web method, JSON-LD documents.

Anatomy of an agent DID
did:web:ais.agentsandswarms.ai:agents:29b7c94a-49cf-436e-aad2-59cc77c7f678
└────────┘ └─────────────────────────┘ └──────┘ └────────────────────────────────┘
  method   |                             |       |
           authority (domain)            namespace agent UUID

Resolves to: https://ais.agentsandswarms.ai/.well-known/did.json
             with publicKeyMultibase + serviceEndpoint[]
Self-registration (zero-auth)

Any agent can register itself. There is no API key gate on POST /v1/register because the new agent has no identity yet — it can't authenticate. Instead:

  1. Agent POSTs name + description
  2. AIS mints a UUID, generates an Ed25519 keypair
  3. AIS issues a fresh bearer token bound to that DID
  4. AIS returns the bearer + a 7-day claim URL

From that moment on, the agent authenticates with the bearer. The bond is unclaimed but the agent works.

Human bonding

A human claims ownership by visiting the claim URL while logged in. AIS:

  1. Verifies the claim token has not expired (7-day TTL)
  2. Issues a Verifiable Credential with the human's DID as subject
  3. Signs it with the platform Ed25519 key (W3C VC-JWT format)
  4. Writes the bond row with type = primary or delegated

Bonds can be no_expiry (permanent) or time-bounded. Delegated bonds grant access without transferring ownership.

OAuth 2.0 Layer 1 (live)

For MCP clients (Claude Desktop, Cursor, Continue, etc.) we expose the standard discovery endpoints:

  • /.well-known/oauth-authorization-server
  • /.well-known/oauth-protected-resource
  • POST /v1/oauth/register (dynamic client registration)

Device-code flow shipped — Layer 2 (authorization-code) is the next milestone. Once Layer 2 ships, mcp-remote can bridge to all 85 tools instead of the npm package's 7.

Privacy wallet + selective disclosure

Built on SD-JWT-VC. An agent can issue a credential about itself with N claims and only reveal a subset to a given verifier. The full claim set is signed; the disclosed subset can be cryptographically proven to belong to that signed set without revealing the rest.

Practical use: an agent shares its skills with a collaborating agent while keeping its memory of the user's personal facts private — and the collaborator can verify the skills claim is authentic without seeing what it doesn't get to see.

Audit trail

Every consent grant, every revocation, and every access is recorded in ais_audit_log with actor, resource, timestamp, and reasoning. The log is append-only at the application layer. For compliance reviews, the audit trail is the source of truth.

Integration surface

Technical perspective · 10

Three on-ramps, all hitting the same backend: REST (any HTTP client), MCP (any LLM client that speaks the protocol), and the aismemory npm package (drop-in for Node/TypeScript agents). Framework-agnostic. No SDK required.

REST API
Plain HTTP. Bearer auth or x-api-key + x-tenant-id headers. JSON in, JSON out. Use it from any language.
150+ routes · OpenAPI
MCP server
Model Context Protocol over stdio or HTTP+SSE. Native integration for Claude Desktop, Cursor, Continue, and any MCP client.
85 tools · OAuth Layer 1
npm package
aismemory@latest — local Node bridge with 7 core memory tools. Activate once, then memory_remember / memory_recall are first-class tool calls.
Device-code flow

Connect in one line

Claude Code, Cursor, Continue, any MCP client
claude mcp add -s user aismemory -- npx -y aismemory@latest
Direct REST — self-register an agent
curl -X POST https://ais.agentsandswarms.ai/v1/register \
  -H "Content-Type: application/json" \
  -d '{"name": "my-agent", "description": "..."}'

# Returns: { agentId, did, bearerToken, claimUrl }
# bearerToken authenticates all subsequent calls

Auth model

Path Auth Used by
POST /v1/register none Self-registering agents
/v1/agents/:id/* bonded bearer token Agents acting on their own behalf
/v1/agents (list) user JWT / service key Operator dashboards
/mcp (HTTP) OAuth 2.0 (device code) mcp-remote bridges
internal worker paths service-role key Embedding backfill, scheduled tasks

All multi-tenant: every request carries either an x-tenant-id header or a bonded-token claim that scopes queries through Postgres RLS. The DB does the isolation; the app cannot accidentally cross tenants.

Scale, performance, quality

Technical perspective · 11

Hard numbers. Where possible, these are pulled from the codebase or production at the time of writing.

Codebase

~68K
LOC · AIS source
~65K
LOC · AIS tests
222
AIS test files
238
SQL migrations

The test-to-source LOC ratio is ~1:1. The discipline is enforced by a branch-protection rule on main that requires a green Type Check job before merge — added after an 8-hour production outage was traced to a single TypeScript error that Railway accepted and the application crashed on.

Retrieval performance

Numbers below are from the latest production-validated runs. The headline figure is today's run with the current methodology; full per-run conditions and the chronological history are tracked in benchmarks/results/HISTORY.md inside the repo.

Benchmark Run Metric Result
LongMemEval 100-Q (per-turn ingest + fact extract) 2026-05-14 · today R@1 23.0%
LongMemEval 100-Q (per-turn ingest + fact extract) 2026-05-14 · today R@5 48.9%
LongMemEval 100-Q (per-turn ingest + fact extract) 2026-05-14 · today R@10 51.1%
↳ single-session-user segment (70 Q) 2026-05-14 R@5 58.6%
↳ multi-session segment (30 Q) 2026-05-14 R@5 26.2%
LongMemEval 500-Q full haystack (blob ingest) 2026-05-13 · Phase 2 RRF R@5 29.2%
LongMemEval 500-Q full haystack 2026-05-11 baseline Ans-Acc (gpt-4o judge) 56.0%
LoCoMo (10 conv · 1,986 QA) 2026-04-20 Evidence Recall 66.7%
SUPERSEDES (35 pairs) 2026-04-20 Accuracy 5.7%

Today's run uses per-turn ingestion with LLM fact extraction on a 100-question subset — that is the direction the retrieval pipeline is moving. The 500-Q full-haystack blob-ingest number from yesterday (2026-05-13) is listed for methodology comparison; the two are not interchangeable. SUPERSEDES extraction is a known regression tracked as CORBOT-67F8BF4A — the relationship-extraction pipeline returns NONE for 97% of test pairs and is being re-instrumented.

Storage scale

91.8K
vectors indexed
179 MB
HNSW on disk
97s
full index build
<50ms
p50 query (incl. RTT)

The HNSW index lives next to the relational data inside the same Postgres. Embedding dimension is 384 (BGE-small-en-v1.5). Index parameters: m=16, ef_construction=100. Index build is one-shot and idempotent; re-runs pick up new rows in seconds.

What we measure honestly

Recall benchmarks (R@K, evidence recall) are not the same as end-to-end answer accuracy (LLM-judge). We separate them. R@K measures "did the right memory come back at all"; answer accuracy measures "did the downstream agent produce the correct answer given the retrieved memory." Both matter; the retrieval layer only fully owns the first.

On LoCoMo, the F1 score (~0.8%) is dramatically lower than evidence recall (66.7%) because the benchmark's answer-grading pipeline produces ungradeable responses for most cases. We publish both numbers and don't paper over the gap.

Operational maturity

Technical perspective · 12

This service has run in production long enough to have scars. Each one became a durable lesson encoded into either the codebase, the CI pipeline, or the deployment process. The list below is incidents we've actually had, with the durable fixes.

Health checks that actually probe

Incident. ChromaDB container went down silently for 14 days. AIS health endpoint reported chromadb.healthy=true the entire time because the check returned true without actually probing Chroma. Vector writes silently failed; FTS fallback masked the outage.

Durable fix. Cut over to pgvector inside the same Postgres — eliminated the dependency. Every health check now round-trips the dependency it claims to verify. No more healthy=true, latency=0.

Self-healing connection pool

Incident. A 1-line TypeScript error in a test file slipped through PR review. Railway failed 17 consecutive deploys. The running container's pg pool exhausted under sustained write load. 8-hour partial outage with 503s on every memory POST.

Durable fix. Two changes. First, PostgresStorageBackend now extends EventEmitter, listens for pool errors, runs a 30-second probe, and reconnects with a circuit breaker. Second, Type Check became a branch-protection requirement — green tsc before merge, no exceptions.

Write-through observability

Every memory write emits a captureAisRequest event to PostHog (latency, embedder used, tier, agent, tenant). Every scheduled probe emits captureAisProbe. Every error path surfaces through Sentry with full stack. Winston handles structured logs and — after one outage where Winston was eating Error stacks — has a logger fix to preserve them through the full transport chain.

Embedding backfill self-healing

Memories without embeddings get progressively embedded by EmbeddingBackfillWorker. The worker is idempotent and per-tenant. If the embedder changes (e.g., BGE-small to BGE-large), legacy memories are grandfathered and the worker drains them opportunistically to the new embedder. Multi-tenant embedder resolution is cached per-tenant; no double-embed cost.

Deploy hygiene

Push to main triggers a Railway deploy. Required CI jobs: type check, lint, unit tests, integration tests. Branch protection blocks bypass. Pre-commit hooks block direct commits to main. Worktree discipline is enforced via a PostToolUse hook that echoes cwd after every edit (we have many parallel worktrees and misrouted edits used to require cherry-pick recovery).

Migration tracking debt

Honest gap: ~40 SQL migrations exist in the repo but were applied manually to production and never recorded in supabase_migrations.schema_migrations. Open issue #1052 tracks reconciliation. The DDL is in production correctly; the bookkeeping is not. New migrations apply cleanly via the standard runner.

Manipulation Filter (safety pipeline)

Memories pass through a safety pipeline on write. Suspicious content lands in ais_memory_quarantine rather than the active store. The filter has false-positive issues on legitimate DevOps content (queries about injection prevention get flagged as injection attempts) — known and tracked. The bias is toward false positives over false negatives.

The honest summary: AIS has had real outages, and each one has produced a durable fix at the layer that failed. No incident has been papered over. The service today is more robust than the one that took these hits — and the next outage will produce its own fix. That is the operating model, not a goal.