Product / AI infrastructure

Alejandr.ia

Cross-agent memory people own: one context store, reachable from every AI they use, with an isolated stack per customer.

  • Python
  • Model Context Protocol
  • OAuth 2.1
  • AWS CDK
  • Lambda
  • DynamoDB
  • CloudFront
  • Amazon Cognito
Alejandr.ia context store One memory shared across every AI a person uses. Each customer gets an isolated stack and an endpoint they paste into any MCP-capable client. ANY MCP-CAPABLE CLIENT PER-CUSTOMER STATE OAUTH 2.1 TOKEN IF_VERSION WHO CHANGED IT Claude web and terminal ChatGPT developer mode Le Chat, Cursor and others EDGE Customer endpoint own domain, own login AS Authorization server dynamic registration API MCP handler stateless, restart-safe DB Documents markdown, versioned DB Audit log per-caller identity The differentiator Customer-owned Any AI client
One endpoint per customer, on their own domain, in a stack that shares nothing with anyone else. The authorization server and the versioned store are highlighted because they are what makes the memory portable and safe to let several agents write to at once.

Overview

A product built out of infrastructure that already existed. Daniel had been running a shared context store for his own agents for a month; Alejandr.ia turns it into something other people can have. A customer gets their own store, their own domain, and an endpoint they paste into whatever AI they already use. The interesting moment is not the first connection, it is the second: the other tool already knows everything.

Problem

Every AI assistant now remembers things, and none of them will ever share that memory with a competitor. Portability across vendors is structurally against the interest of the companies building them, so the gap does not close on its own. Meanwhile the practical version of the problem is unglamorous: a small team where everyone uses a different assistant, and all of those assistants confidently state different versions of the same client facts.

Solution

A context store exposed over the Model Context Protocol, which is the one interface every major assistant has converged on. Documents are markdown, so a human can read and edit them without the product in the way. Each customer gets a stack of their own rather than a row in a shared table, which is both the isolation story and the answer to a customer who later wants to run it themselves. Onboarding is the hard part of a memory product, because an empty store is worthless, so the intended entry point is importing an existing assistant history rather than starting from a blank page.

Architecture

One CDK stack per instance, sharing nothing: its own table, credential pool, function, distribution and domain. The protocol handler is stateless HTTP rather than a long-lived stream, which matters more than it sounds: a streaming server keeps per-client session state, so restarting it orphans every connected client and they do not renegotiate, failing afterwards with an error that names the wrong cause. A stateless handler has no session to lose. Authorization is an OAuth 2.1 server written for this rather than delegated to a hosted login page, including dynamic client registration, because one major client will not let a user paste credentials by hand and simply requires the server to support it.

Key decisions

Sell to small teams rather than to developers or to individuals. The developer-infrastructure segment is a feature war against funded companies, and the personal-diary segment has to keep answering why the built-in memory is not enough. A five-person agency has a nameable pain and already buys software. Keep the write path honest with optimistic concurrency: several agents writing one document is routine here, not an edge case, and a version guard turns a silent overwrite into a conflict the caller can merge. Log the caller identity on every write, because the moment agents can write, the question stops being what changed and becomes which one of them changed it. And deliberately leave out the rich editor, real-time collaboration and semantic search, none of which the first version needs.

Challenges

Two platform behaviours cost real time, and both looked like application bugs. A function URL silently renames the authentication challenge header, so a spec-compliant client sees no challenge at all. Worse, the obvious fix does not work: an edge function that restores the header passes its own test harness perfectly and then does nothing in production, because those functions do not run on error responses, which is exactly when the challenge matters. The working answer was a static response-headers policy instead. The recurring lesson is that when a protocol handshake fails at the edge, the platform is a likelier suspect than the code, and the test harness may not exercise the path that actually breaks.

Outcome

Two instances running, one of them for the first outside tester, each on its own domain with its own branded login, verified end to end by a suite that drives the whole authorization flow headlessly including the version-conflict case. It is early and unproven commercially, and it is deliberately in front of one real user before anything else. As engineering evidence it is the clearest single artefact here: a product shaped by a month of running the same thing in anger, where the differentiated parts are scar tissue rather than roadmap.

Wondering if Daniel is a fit? Ask his assistant, hiring, contracts, or collaboration.