Fraglets: Composable Building Blocks of Identity

You're relocating to a new city. Your agent needs to work with estate agents, schools, local services, and neighbourhood searches simultaneously. Each one needs context about who you are and what matters to you. None of them have it. A scientific equipment supplier wants to recommend products to a laboratory, but has no structured picture of its needs. A financial adviser meeting a new client needs to understand not just numbers but their relationship with risk. In each case, the agent or service needs structured context about who it's working with, and it has no way to get it.

The conventional approach is to build that understanding internally: track behaviour, infer preferences, and gradually assemble a model. This works, but it creates three persistent problems.

First, cold start. Every new service begins blind. Until a user has generated enough behavioural data on that specific platform, recommendations are generic at best. The user's rich history elsewhere is inaccessible.

Second, opacity. The resulting models are opaque to the user. You cannot see what Spotify thinks you like, edit Netflix's model of your viewing taste, or correct a recruitment platform's assumptions about your working style. Preference is inferred, never stated.

Third, non-portability. Each model is locked inside the platform that built it. A decade of carefully calibrated food preferences on one service cannot be carried to another. The user rebuilds from scratch, repeatedly.

These are not technical failures of individual platforms. They are structural consequences of an architecture in which context about people and organisations is always platform-owned and platform-scoped. The fraglet proposes a different architecture: make yourself legible. Extract characteristics into structured, portable descriptions that any agent or service can read and act on. You choose what to present, and in which contexts.

The past eighteen months have seen a convergence of regulatory pressure, open-protocol development, and commercial investment around the idea that personal context should not be locked inside platforms. Several serious initiatives are now in play, each addressing a genuine and valuable part of the problem.

The Human Context Protocol (HCP), developed by researchers at MIT, Stanford, Oxford, and Google DeepMind, proposes a user-centric architecture for preference governance. Users maintain a centralised vault of structured preferences, and AI services access relevant subsets through mediated interfaces with scoped permissions and revocation controls. HCP offers a strong model for consent and access scoping, explicitly designed to complement the Model Context Protocol (MCP).

The Personal Context Protocol (PCP) takes a more pragmatic approach: a persistent personal data node that stores durable facts, preferences, and AI-generated summaries. Applications connect via MCP-compatible configuration and request specific read permissions. PCP focuses on the practical problem of re-explaining context to every new AI tool.

The Open Context Layer (OCL), from Plurality Network, is a decentralised memory protocol that lets users carry preferences, goals, and behaviour across applications and agents. Built on encryption and multi-party compute, OCL stores context as vectorised embeddings with standardised schemas, accessible through a universal API.

Mem0 provides an open-source memory layer between applications and LLMs. It automatically extracts, stores, and retrieves relevant information from conversations across three memory scopes: user, session, and agent. With over 41,000 GitHub stars and selection as AWS's exclusive memory provider for their Agent SDK, Mem0 represents significant traction in the conversational memory space.

The Data Transfer Initiative (DTI) has published principles for AI data portability, collaborated with Inflection AI on transferring conversational histories, and advises on DMA implementation. Regulatory tailwinds are building: the EU Digital Markets Act's one-year review is expected to classify conversational AI as a Virtual Assistant with targeted data portability obligations; the UK's Data Use and Access Act reached Royal Assent in June 2025; and over 1,100 AI-related bills were introduced in US states in 2025 alone.

These initiatives cluster around two related problems: conversational memory (how to stop re-explaining yourself to AI assistants) and preference governance (how to own and control your preference data across AI services). Both are valuable. But they leave three problems unaddressed:

Existing protocols are fundamentally personal data stores: one person, one vault, private by default. They answer the question "What does this person prefer?" Fraglets address different questions. Which characteristics are relevant here, and at what level of detail? What persona should I present in this situation? And they do so with a model that is shareable, adoptable, composable, and agent-readable.

These initiatives are complementary, not competitive. HCP could govern which services access a user's fraglets. PCP and OCL could store references to fraglets alongside other context. Mem0 could learn from fraglet interactions. MCP provides the transport layer: fraglets are already accessible as MCP tools, and any MCP-compatible agent can read, create, and manage them. DTI's portability principles inform fraglet server governance. Fraglets occupy a specific niche: structured, portable identity that agents and services can read.

A fraglet is a structured, portable unit of characteristics within a given domain. It is composed of human-readable descriptive fields (a title, a brief summary, a detailed narrative, categorical tags, and domain-specific extensions) alongside a high-dimensional vector embedding derived from those fields. The dual representation matters: a fraglet is legible to people and computable by machines at the same time.

The term combines fragment with the diminutive -let. A fraglet is intentionally small: it captures a single facet, not a comprehensive profile. A jazz listener's late-night sensibility is one fraglet; their weekend brunch preferences might be another. A neighbourhood's architectural character is one fraglet; its dining scene is a separate one.

Characteristics are not monolithic. A person's relationship with music is not one thing. A venue's identity is not one thing. By making the unit of exchange a single facet rather than a complete portrait, fraglets stay small enough to share and specific enough to be useful. Multiple fraglets can be combined to build a richer picture when needed, without requiring any single fraglet to carry the full burden of description.

Fraglets are not limited to describing people. A venue, a neighbourhood, a product, a team, or a service can all be described by fraglets. The schema makes no assumption about what the subject is, only that its characteristics can be expressed in structured natural language and compared by semantic similarity.

Five properties define a fraglet:

The architectural decision that most distinguishes fraglets from existing personal context systems: users do not own fraglets. They associate with them.

A fraglet entity contains no user references. The association between a person and a fraglet is managed server-side as a separate concern. Multiple people can associate with the same fraglet. A fraglet exists independently of any single person's relationship to it.

A fundamentally different model from a personal data store:

In each case, the fraglet is a shared artefact, not a personal record. Authored by one, meaningful to many. It can be created by a service, an organisation, or a community, not only by individuals. The association model enables collaborative, forkable structures around characteristics. No personal context vault is designed to do this.

A fraglet begins with a signal: a playlist, a set of favourites, a list of liked items, or a free-text description of characteristics. The signal can come from an existing platform via API or from direct input.

A large language model analyses the input and produces a structured JSON object constrained to the fraglet schema: a descriptive title, a brief summary, a detailed narrative, categorical tags, and domain-specific extensions. The LLM's role is translating unstructured signals into the structured form the schema requires.

The descriptive text fields are then passed through an embedding model to produce a high-dimensional vector. This embedding captures the semantic essence of the fraglet, enabling similarity computation against item catalogues.

Finally, the user reviews the generated fraglet, modifies any fields that don't accurately reflect their characteristics, and saves it. The embedding is regenerated to reflect edits. LLM generation is optional. A conforming server can also accept fraglets where the user provides all text fields directly.

When a fraglet is published with open visibility, anyone can adopt it: associating with it as-is, or using it as a starting point for their own variation.

Adoption is not copying in the conventional sense. When a person adopts a fraglet, they associate with the existing entity. If they want to modify it, they derive a new fraglet with a parent_id referencing the original. The original persists, unchanged, for everyone else who associates with it.

The result is a social layer around characteristics that doesn't require a social network. People discover fraglets that resonate with them, associate with them or build on them, and over time a distributed graph of shared profiles emerges.

Because fraglets are immutable, every modification creates a new entity linked to its parent. Over time, this produces derivation chains: sequences of fraglets that show how a set of characteristics has evolved, branched, and been reinterpreted by different people.

A single fraglet may have multiple children, created by different people who each took the original in a different direction. The chain preserves provenance without constraining evolution. This is closer to a version history in a collaborative document than to a mutable profile that overwrites itself.

Individual fraglets capture single facets. But real situations are multi-dimensional. A date night involves food, music, and transport. A business trip involves hotels, solo dining, and working-space preferences. No single fraglet covers this.

A jacket is a named, ordered collection of fraglets that acts as a persona. Jackets are cross-domain by design. A date-night jacket might combine food preferences, a cocktail fraglet discovered from someone else, and a live-music sensibility. A work-travel jacket might focus on hotel preferences and solo dining.

The fraglets in a jacket do not all need to come from the same person. A jacket can include your own creations, fraglets you have adopted from others, and adapted versions of both. A food critic publishes their palate as an open fraglet; you include it in your going-out jacket alongside your own music taste and a cocktail fraglet a friend shared. The composition is the creative act.

A jacket follows the same immutability pattern as fraglets. Once other users associate with a jacket, its composition is frozen. The creator can still modify their own experience by adapting: forking a new jacket with changes, linked to the original via a parent reference. The original remains intact for everyone who associated with it.

Associations can be live or snapshot. A live association always reflects the jacket's current composition. A snapshot captures the composition at association time and does not change unless the user explicitly refreshes it. The choice is per-association, not per-jacket.

Jackets turn fraglets from individual data points into something more interesting. A published jacket is a curated combination of characteristics that others can try on, adapt, or build from. An editorial "72 hours in Edinburgh" jacket. A friend's going-out persona. A seasonal jacket updated each quarter. The composition layer is where fraglets become collaborative.

Fraglets are designed to be read and presented by AI agents acting on a user's behalf. The integration mechanism is the Model Context Protocol (MCP). Any MCP-compatible agent can interact with fraglets as tools, without custom integration or an SDK.

The key architectural component is the picker: an LLM-mediated tool that selects which fraglets are relevant to a given intent and at what level of detail. When an agent needs to find a restaurant for tonight, the picker selects food fraglets at summary level. When a service needs detailed musical preferences for playlist generation, the picker returns music fraglets at full detail.

The picker is not a filter. It is a selector with judgement. It reads the full set of a user's fraglets, understands the intent, and returns the subset that matters, at the resolution that is appropriate. This is a different operation from "retrieve all preferences" or "run cosine similarity." It adds intelligent mediation between a user's full identity and what any single service needs to see.

The picker can be scoped through a jacket. In context mode (the default), the jacket biases the picker's selections: fraglets in the jacket are prioritised, but the picker can still draw from outside the jacket when clearly relevant. In strict mode, the picker is limited to the jacket's fraglets only. Strict mode exists for situations where the user wants tight control over what gets shared.

This solves a practical problem. A business jacket does not contain food fraglets, but a work dinner needs both business context and dining preferences. Context mode handles this naturally: the jacket provides the frame, the picker fills in the gaps.

Beyond the picker, the full fraglet lifecycle is available as MCP tools: creating fraglets, discovering open ones, associating with fraglets from others, building and managing jackets, and controlling visibility. An agent can help a user build their fraglet collection, compose jackets, and present the right identity to the right service, with the user approving each action.

Every fraglet has one of three visibility levels, set by its creator:

Open visibility combined with the association model creates a commons for structured profiles. A shared space where characteristics can be published, discovered, and built upon.

Fraglets are hosted at fraglet.org: a centralised service that stores, manages, and serves fraglets over a standard API. Any developer can register, receive an API key, and start creating and consuming fraglets immediately. The service is designed around the same authentication pattern as Stripe or OpenAI: a prefixed key (frag_live_) used as a Bearer token.

A centralised service eliminates the discovery and trust problems that federated architectures introduce. Every fraglet lives at the same host, addressable at a stable URI. The service conforms to three design requirements:

Server capabilities are published at a well-known metadata endpoint (/.well-known/fraglets), declaring the embedding model, supported domains, and API base URL. The schema and protocol are open. Nothing prevents future federation if the ecosystem grows to warrant it, but a single canonical service is the right starting point for establishing the pattern and ensuring consistency.

Agents and services can read fraglet text fields directly to inform decisions. But the embedding vector also enables a more specific operation: direct similarity computation against item catalogues. When a service embeds its catalogue items using the same model, cosine similarity between the fraglet vector and item vectors produces a ranked list of matches.

The embedding is composed from three fields, each contributing differently to the semantic signal:

This composition means the embedding reflects both the texture of the narrative (what makes this profile distinctive) and the structure of the domain (what categories and attributes apply). The result is a vector that captures semantic similarity more effectively than keyword matching or category-based filtering.

When a user associates with multiple fraglets within the same domain, their combined signal can be represented by averaging the embedding vectors. This produces a blended profile that reflects the breadth of their characteristics. Services can also match against individual fraglets separately, presenting results grouped by facet.

The progressive detail structure makes this practical for group matching, finding items that suit multiple people at once. A service can collect one fraglet from each person in a group, average the embeddings, and match the result against its catalogue. Because each fraglet is a focused unit, the combined signal remains coherent rather than dissolving into noise. And because the text fields are progressively detailed, the service can present the group with a readable summary of what was combined: a list of titles ("Nocturnal jazz wanderer", "Festival-stage rock fan", "Ambient explorer") is immediately legible in a way that a merged preference blob is not.

A group of friends finding a restaurant, a team choosing an offsite location, a household selecting an energy tariff. In each case, the unit nature of fraglets (small, focused, composable) makes combination tractable where a comprehensive profile would not be.

Vector similarity provides efficient retrieval, but the top results can be further refined. An optional re-ranking step passes the fraglet's text fields and the candidate items' descriptions to an LLM, which produces an explained ranking. This adds interpretability: the user sees not just what matched but why.

The fraglet pattern works across domains. Any context where structured characteristics need to be legible to agents and services is a candidate, whether that involves catalogue matching, agent decision-making, or simply giving a service context about who it is working with.

MostMaker is a personalised restaurant and live music discovery service for London. Users connect Spotify playlists or select artists; an LLM produces a structured music fraglet; pgvector cosine similarity ranks hundreds of upcoming gigs against the fraglet embedding. The result is a personalised gig feed that reflects the user's actual taste rather than generic genre categories. The same pattern applies to restaurant recommendations matched against food fraglets.

MostMaker demonstrates the full pipeline: signal acquisition, LLM-based generation, embedding, user refinement, and catalogue matching. It validates that the pattern works at production scale and produces recommendations users find genuinely useful.

A B2B deployment applies the same architecture to industrial product catalogues. Hundreds of fraglets describing organisational requirements are matched against tens of thousands of product standards using the same vector similarity pipeline. The domain is entirely different from entertainment. The mechanism is identical.

This validates that fraglets are not tied to taste or lifestyle. Any domain where characteristics can be expressed in natural language and compared by semantic similarity is a candidate.

fraglet.com is the consumer platform where users create, discover, adapt, and compose fraglets. It includes an MCP server for agent integration, the picker for intelligent fraglet selection, and a pairwise jacket builder that helps users compose personas from their fraglets without stereotyping or category assumptions.

The mechanism is not tied to any particular domain. The dual representation (structured text plus vector embedding) works for any set of characteristics that can be expressed in natural language and compared by semantic similarity.

Property search (neighbourhood character, lifestyle fit), professional matching (working style, intellectual interests), travel planning (sensibility, pace, priorities), energy services (consumption patterns, household characteristics). In each case, the same architecture applies: structured characteristics that agents and services can read, reason about, and where relevant, match against catalogues.

The association model becomes particularly interesting in these broader domains. A neighbourhood could publish a fraglet describing its character; residents associate with it. A company could publish fraglets describing its team cultures; candidates discover them. The fraglet becomes a shared description that multiple parties relate to, not a private record that one person carries.

The domain field is open-ended. New domains require no changes to the schema or protocol, only conventions for the additional field, which communities can define and publish independently.

The fraglet architecture is production-tested but not fully resolved. Several questions remain open, and addressing them honestly is part of the work.

Fraglet embeddings are only comparable when generated by the same model. A fraglet embedded with text-embedding-3-large cannot be directly compared to an item embedded with a different model. The current specification requires servers to declare their embedding model at the metadata endpoint, and consumers to verify compatibility. Whether the protocol should specify a canonical model or define an alignment mechanism between models remains an open design question.

Fraglets are comparable only within the same domain. Whether meaningful cross-domain comparisons are possible, or desirable, is unclear. A music fraglet and a food fraglet occupy the same embedding space but describe fundamentally different things. The protocol currently treats domains as separate namespaces.

The schema will need to evolve. Because fraglets are immutable, older fraglets remain valid even as the schema changes. But a versioning strategy is needed to ensure new servers can handle old fraglets and vice versa.

Could open fraglets be used for profiling or manipulation? The privacy-preserving design (no personal data, only characteristic expression) mitigates but does not eliminate this risk. A fraglet reveals nothing about who associates with it, but the characteristics it describes could be sensitive in certain contexts.

If nobody owns a fraglet, who is responsible for harmful content? The current model assigns deletion rights to the creator, but open fraglets adopted by many users create a tension between individual authorship and collective use. Governance models for community-maintained fraglets are not yet defined.

A single fraglet reveals little about who created it. A curated combination of fraglets in a jacket is another matter. A specific mix of food, music, travel, and hobby preferences, even without names or locations, could be distinctive enough to identify someone. The system currently warns users when they publish a jacket, but whether that is sufficient, and whether automated identifiability scoring is feasible, remains open.

When an agent presents fraglets to a service on a user's behalf, how does the service verify that the fraglets are genuine user-curated artefacts, not fabricated by the agent? The current model relies on the fraglet server as the source of truth: fraglets exist at stable URIs and can be independently verified. But the question of whether an agent faithfully represents a user's chosen fraglets, versus selecting or modifying them for its own purposes, is not yet addressed at the protocol level.

The current architecture is centralised: fraglet.org is the canonical service. If the ecosystem grows to warrant multiple servers, the open schema and protocol make federation possible without redesigning the fraglet model itself. The questions of server trust, discovery, and cross-server identity would need to be addressed at that point, but the centralised starting point lets the pattern establish itself without premature architectural complexity.

Fraglets are infrastructure for composable identity. Structured descriptions that give agents and services the context they need to act competently on someone's behalf. Portable, shareable, and not locked to any single service.

The architecture rests on three choices. Dual representation: every fraglet is both human-readable and machine-computable, always in sync. Association rather than ownership: fraglets are shared artefacts that anyone can relate to, adopt, and build upon. And composition: jackets let users assemble personas from any combination of fraglets, switching between presentations of identity for different contexts.

AI agents are the primary consumers. The picker selects relevant fraglets for any intent, at the right level of detail, optionally scoped through a jacket. The full lifecycle is available as MCP tools. Three production deployments validate the pattern across entertainment, B2B product discovery, and the consumer platform itself.

Fraglets complement existing personal context protocols. They fill a gap that conversational memory and preference governance do not address: giving users structured identity they choose how to present, and giving agents the context to act on it, across services that share no platform, no model, and no memory layer.