# 🥽 Plastic Labs

> A blog

Website: https://blog.plasticlabs.ai

## Contents

### Home

Welcome to Plastic Labs' blog.

Date: 2025-12-19
URL: https://blog.plasticlabs.ai/
Tags: honcho, neuromancer, chat, penny, yousim, grants



                  
                  WELCOME TO PLASTIC LABS
                  
                

Here you'll find our blog, research, and public notes. You can also engage with the ideas directly.
Plastic is an engineering-driven AI lab building at the intersection of machine learning and cognitive science.
Our focus is developing Honcho, an AI-native memory solution powered by our state-of-the-art reasoning models. Honcho is a continual learning system for modeling personal identity, and soon a shared context layer for individual alignment.
The foundational layer of intelligence being built is just the beginning. Latent among the scores of specialized secondary and tertiary layers yet to be realized exists one for personal identity.
We're building it.


Guide
We post a few different types of content here:

Blog - Deep dives into the cogsci, development, & ML underpinning our projects
Research - Preprint or blog-style research we've made public
Notes - Short-form working notes on Plastic theses
Archive - Legacy content about out-of-date or depreciated projects & features
Careers - Open positions at Plastic

Subscribe to updates.
Projects
Explore our active projects:
PRODUCTS

Honcho - AI-native memory & reasoning infra for apps & agents honcho
Neuromancer - Reasoning models for memory & personal identity neuromancer

DEMOS

Honcho Chat - Honcho-powered AI-assistant platform with SOTA memory chat
Penny for Your Thoughts - Honcho/x402-powered personal expertise market penny
YouSim - Honcho-powered identity simulator yousim

COMMUNITY

Xeno Grant - Direct-to-agent grants program grants



                  
                  For Agent Readers 
                  
                

This site provides machine-readable content via llms.txt files, available on every page for LLM consumption. The full blog content can be found at llms-full.txt.



---

### Benchmarking Honcho

Honcho achieves state-of-the-art performance and pareto dominance across the LongMem, LoCoMo, and BEAM memory benchmarks.

Date: 2025-12-19
URL: https://blog.plasticlabs.ai/research/Benchmarking-Honcho
Tags: announcements, dev, honcho, evals

TL;DR
Honcho achieves state-of-the-art performance across the LongMem, LoCoMo, and BEAM memory benchmarks. 90.4% on LongMem S (92.6% with Gemini 3 Pro), 89.9% on LoCoMo (beating our previous score of 86.9%), and top scores across all BEAM tests. We do so while maintaining competitive token efficiency.
But recall tested in benchmarks which fit within a context window is no longer particularly meaningful. Beyond simple recall, Honcho reasons over memory and empowers frontier models to reason across more tokens than their context windows support. Go to evals.honcho.dev for charts and comparisons.
1. A primer on Honcho's architecture
Read Honcho's documentation for a full understanding of how Honcho works, but a brief overview is important for understanding our benchmarking methodology and how Honcho achieves state-of-the-art results:


Honcho is a 'memory agent': it runs as a server which ingests messages, reasons, and exposes a variety of query endpoints.


When a message or batch of messages is stored in Honcho, it uses small fine-tuned models to capture all latent information and save it as a 'Representation' of the author1.


In the background, Honcho regularly 'dreams'2 across ingested messages and prior reasoning to make deductions and reach further conclusions.


Honcho's API exposes a chat endpoint containing a research agent that uses a powerful model to call tools and get the best possible answer to any natural language query.


For the sake of reproducibility, all benchmark results published here were generated using gemini-2.5-flash-lite as the ingestion model and claude-haiku-4-5 as the chat endpoint model. In practice, Honcho uses a variety of models for these roles as well as within the dreaming processes.
We also tune Honcho for various use cases. For example, the message batch size when ingesting messages and the amount of tokens spent on dreaming both have an effect on performance. Notes on the configuration for each benchmark are included, and the full configuration for each run is included in the data.
2. Memory Benchmarks
We currently use 3 different benchmarks to evaluate Honcho: LongMem, LoCoMo, and BEAM.
LongMem
LongMem S is a data set containing 500 "needle in a haystack" questions, each with about 550 messages distributed over 50 sessions, totaling ~115,000 tokens of context per question.
After ingesting this context, a single query is made and judged. The correct answer hinges on information divulged in one or a handful of messages: these are the "needles." Everything else is "hay." The questions come in six flavors:

single-session-user
single-session-assistant
single-session-preference
multi-session
temporal-reasoning
knowledge-update

Answers are canonically judged using GPT-4o with a prompt defined in the LongMem paper3. The prompt varies based on the question type.
Notably, LongMem does not test a memory system's ability to recall across truly large quantities of data: each question's message history fits comfortably within the context window of most modern LLMs. LongMem was originally designed, and still serves, to highlight an important phenomenon in LLM context windows: just because some information is within the context window does not mean a model can productively recall it.
Running LongMem with Claude Haiku 4.5 without any augmentation–merely dropping the full conversation preceding a question into the context window, then asking the question–yields a score of 62.6%. Rather than comparing this to a theoretical score of 100%, though, this score should be compared to the same model run against LongMem Oracle: The same questions as the 'S' data set, but with only the one-to-three sessions containing the needle(s). Claude Haiku 4.5 scores 89.2%. So, adding 115,000 tokens of 'hay' leads to a 26.6% dropoff in performance. This behavior is fairly consistent across models, with smaller models generally displaying even larger dropoff and the highest-tier of frontier models holding up slightly better.
Another key fact about LongMem revealed by the Oracle variant is that there's a component of reasoning, not just recall. Failures on Oracle questions mean that the model simply isn't smart enough to generate the correct answer4. We can therefore treat the Oracle score for a given model as a (very) rough indicator of the ceiling at which that model can operate within a memory framework.
With Claude Haiku 4.5 as the 'chat engine' model, Honcho scores 90.4% on LongMem S. 91.8% on LongMem Oracle. Almost no dropoff in recall. In fact, Honcho empowers the model running inside to perform better with fewer tokens: The chat endpoint uses a median 5%, mean 11% of the question's context to answer correctly 90.4% of the time–that's better than the same model on the minimized data set containing only the answers!
Token efficiency at this level allows us to use more expensive models on the chat endpoint, leading to higher quality reasoning over the total latent information extracted from content ingested by Honcho. More on this in section 3.
Full results:















































CategoryPassedTotalSuccess RateSingle-Session Assistant545696.4%Knowledge Update747894.9%Single-Session User667094.3%Single-Session Preference273090.0%Temporal Reasoning11813388.7%Multi-Session11313385.0%
Configuration: 16,384 tokens per message batch, dreaming OFF. Full data.
LongMem M is the big brother to S. Each question has roughly 500 sessions, equivalent to over 1M tokens.
We asked Honcho 98 questions from LongMem M, and scored 88.8% using the same configuration that we used for S. That's a less than 2% dropoff when injecting about a million extra tokens of "hay" into the source material: real evidence that Honcho is effectively expanding the ability of a model to reason over tokens beyond context window limits.
But just adding extra noise to a conversation history isn't really getting at what we think of when we use the word "memory." Eliminating irrelevant data mostly comes down to optimizing RAG strategy and designing good search tools for an agent. True memory involves processing everything, even the "irrelevant" data, and using it to form a mental model of the author. The retrieval questions in LongMem don't get more nuanced with more data, and Honcho can easily eliminate noise to find the answer while doing much more behind the scenes.
A note on model selection
LongMem has been fashionable over the past year as a benchmark for anyone releasing an agent memory system. It's important to remember that when the benchmark was first released, GPT-4o scored 60.6% on LongMem S without augmentation. It was a clear demonstration that token-space memory augmentation had a place even in the scale of 100,000 tokens or less, even before questions of cost-efficiency.
After over a year, this is no longer the case. Gemini 3 Pro can run LongMem S, easily fitting the per-question ~115k tokens into its context window, and score 92.0%. By itself. This score is higher than any published LongMem score by a memory framework project, including two that actually used Gemini 3 Pro as their response-generating model for the eval. Their systems are degrading the latent capability of the model5. Honcho with Gemini 3 Pro scores 92.6%. We're not impressed by that marginal improvement, though it's good to know we're not actively impeding the model. All these results reveal is that from here on out, memory frameworks cannot merely announce scores on low-token-count tests. There are two ways to prove a memory framework is useful:


Demonstrate recall over more tokens than fit in the context window of top-tier models today: one million or more.


Demonstrate cost efficiency: calculate the cost of ingesting a certain number of tokens with a top-tier model to produce a correct answer, then get the same answer by spending less money on input tokens using a memory tool.


Honcho passes both of these tests. Running LongMem S directly with Gemini 3 Pro costs about $115 for input tokens alone (the relevant part for retrieval–output tokens don't really change). Honcho with the same model had a mean token efficiency of 16% -- bringing ingestion cost down to $18.40. Adding the cost of running Honcho's ingestion system with Gemini 2.5 flash-lite, a model quite effective for the task, brings total cost up to $47.15 -- a 60% cost reduction. The Honcho managed service does not charge for ingestion -- we operate our own fine-tuned models for the task. For more discussion of cost efficiency, see section 3.
LoCoMo
We stated regarding LongMem that it "does not test a memory system's ability to recall across truly large quantities of data": this is even more the case for LoCoMo. It takes a similar format to LongMem, but instead of 115,000 tokens per question, it provides a meager 16,000 tokens on average of context. Then, each of these 16k token conversations has a battery of 100 or more questions applied to them.
Given that models routinely offer a context window of 200,000 or more tokens nowadays, a 16,000 token conversation really isn't useful at all for evaluating a memory framework.
Even still, Honcho ekes out better performance on the test than a model acting alone. We score 89.9% on the full LoCoMo benchmark. Haiku alone scores 83.9%6. For reference, that means Honcho answers about 100 questions that the model acting alone cannot. Improvement is spread fairly evenly across all question categories, which makes sense given the small context size (the model isn't really experiencing 'forgetfulness' due to context overload) and our dreaming methodology that reasons over the data in the background before any questions are asked.



































CategoryPassedTotalSuccess RateCommonsense78484193.2%Multi-Hop28332188.2%Single-Hop23728284.0%Temporal749677.1%
Configuration: 128 tokens per message batch (1-5 messages per batch, in practice), dreaming ON. Full data.
BEAM
At this point, you might be asking yourself: can any so-called memory benchmarks really test a memory framework?
BEAM, "BEyond A Million" Tokens, is your answer.
BEAM comes in four flavors: 100K, 500K, 1M, and 10M. Those stand, loosely, for the number of tokens provided as context for the evaluation's questions. Released in October 2025, BEAM introduces a high-quality set of conversations and questions spanning up to ten million tokens. The paper also introduces a memory framework of its own, noting an improvement of 3-12% over baseline. Like the previous benchmarks, BEAM measures the phenomenon of LLMs exhibiting forgetfulness as the context window fills up. We believe it also uniquely judges the ability of a memory framework to empower LLMs to reason beyond the context window.
BEAM's judge is thoroughly defined, including a rubric, tool calls, and detailed prompts for multiple question types. Many of BEAM's question categories look familiar: temporal reasoning, multi-session reasoning, knowledge update, abstention, and preference following. It also introduces some new categories not tested in the other benchmarks: contradiction resolution, event ordering, information extraction, instruction following, and summarization.
BEAM scoring is different from LongMem and LoCoMo: rather than setting a pass/fail criterion and scoring the overall test by pass rate, BEAM's judge grades each question individually, and the overall test grade is the average of these scores. The LLM judge is instructed to, and naturally leans towards, grading in a step-function pattern: each question's rubric makes it relatively easy to "pass" with a 0.5, and quite difficult to "ace" the question and score 1.0. A score of 0.5 would count as a "pass" in both the LongMem and LoCoMo judge systems. This property gives BEAM scores a much higher ceiling of excellence, and testing Honcho with BEAM has given insight into how we can improve our system beyond just "perfect recall."
Honcho produces state-of-the-art scores according to the judgment framework proposed by the paper. On the smallest test, BEAM 100K, we observe a baseline score of 0.53 from Claude Haiku 4.5, and a Honcho score of 0.63. Since Haiku only has a context window of 200,000 tokens, the baseline scores stop there. But Honcho continues:








































BEAMTop Score in PaperHoncho ScoreDreamingBatching100K0.3580.630ON8,192500K0.3590.649OFF4,0961M0.3360.631OFF4,09610M0.2660.406OFF4,096
Full data.
Notably, there's no dropoff in recall performance until 10 million tokens (though it likely begins after a few million).

Some patterns emerge across all benchmarks. Questions that simply require recall of an entity's preference or a biographical fact about them are easy: Honcho pretty much aces these, and baseline tests fare well too. Across single-session-user and single-session-assistant questions in LongMem, for example, we pass 95%. We score 0.95–nearly perfect–on BEAM 500K's preference-following section.
Questions that ask about temporal reasoning are trickier: 88.7% in LongMem, 77% in LoCoMo, 0.49 in BEAM 500K. Frustratingly, these are some of the most common types of questions that a user comes across when subjectively evaluating an agent's memory. While Honcho significantly improves an LLM's ability to deal with questions about time, this is a genuine weak point of all models available today. It's part of what leads many users to continually underestimate the intellect of various models. Many models, when asked, will refuse to believe the current date if told, instead insisting that their training cutoff defines the current moment. We will continue to research this flaw and apply best-in-class solutions.
No benchmark is perfect. Across all three, we've noticed a scattering of questions that are either outright incorrect or trigger high variance in models. These are especially prevalent in temporal reasoning questions: if a user has a discussion with an assistant in 2025 about having first met their spouse in 2018, and having been together for five years, there's meaningful ambiguity about how long the user knew their spouse before dating. Ambiguity arises both in measurements of time (when in 2018 did they meet?) and semantics (did they start dating when they first met, and have been married for five years, or did they meet and then actually start dating two years later?). Each benchmark has dozens of questions with ambiguous answers, with at least a couple outright wrong answers. These are the perils of synthetic data.
We also find that the best answer for a benchmark does not always align with the best answer for an interactive tool. Like a multiple-choice test, benchmarks reward confidently guessing and moving on if the answer is unclear. In the real world, we would prefer Honcho to interact with the user or agent and prompt them to clarify what they meant, and we've stuck to this behavior even in the configurations of Honcho that we run benchmarks on.
3. Benchmarking cost efficiency
Honcho demonstrates excellent cost efficiency and can be used to significantly reduce the cost of using expensive LLMs in production applications.
The cost savings from using Honcho scale with 2 primary factors: the amount of content ingested and the number of queries made against the content. With a sufficient amount of data (about 100,000 tokens), savings occur after just a single question. Conversely, if only reasoning over a few thousand tokens, Honcho never confers cost savings and most use cases with such minimal context needs would be better served by just populating the context window directly.
Note: these cost calculations use the open-source Honcho software -- Honcho is also offered as a managed SaaS service that passes most savings directly to the user, and employs powerful fine-tuned models for even better performance.


(In the above charts, comparisons are made using Claude Haiku 4.5 in Honcho vs. directly. We've also created a calculator that generates the same data with several models on our eval page)
Token efficiency here refers to the number of tokens used in various memory benchmarks to answer a question divided by the total context available for that question. A lower number is therefore better. Empirically we observe that below about 50,000 tokens, Honcho's efficiency can approach or even exceed 100%, meaning that the chat endpoint agent uses as many or more tokens to answer the question as are available in the base data set. This is due to prompt and tool-calling overhead plus the fact that more complex questions and data prompt the agent to attempt to be exhaustive in its search for the truth. As the data set grows, though, efficiency scales rapidly. We observe that Honcho has an average 11% efficiency during the LongMem benchmark, meaning it uses on average only ~12,650 of the ~115,000 available tokens to answer each question. Token efficiency continues to improve over massive scales, with Honcho averaging 0.5% efficiency during BEAM 10M.
Notably, these calculations scale with more expensive models. Haiku token input is fairly cheap at $1 per million tokens. A more expensive model means Honcho confers savings even faster.
Example scenario 1:
Over the course of just a few days, a user chatting regularly with an AI assistant can produce 250,000+ tokens of message history. Sharing this history with a powerful research model like GPT-5-Pro would cost $3.75 for a single question. Using Honcho, both ingesting this context and querying it once would cost only ~$0.15. If an expensive model is necessary to complete a task, it would be foolish not to expose Honcho's chat endpoint to it as a tool, allowing the expensive model to provide its superior reasoning across only the relevant context. Repeated queries across a long message history with Honcho will rapidly save hundreds of dollars for a single user.
Example scenario 2:
A matchmaking system with thousands of users wants to use Claude Opus 4.5 to create high-quality "date me" docs for each user who has volunteered their email inbox as source material to extract their lifestyle and preference data. Rather than having Opus churn through 10M+ tokens per inbox, costing $50+ per user, use Honcho to ingest the data and perform a dozen targeted chat queries: using the same configuration as the BEAM 10M benchmark run above, this would cost about $6.
Conclusion
We're glad to hit state-of-the-art numbers—they validate that our architecture works—but scores on LongMem or LoCoMo are not the final goal. And it turns out that these benchmarks are starting to lead people astray from what agent memory really means. Other memory systems, focused only on recall, are beginning to underperform baseline with the latest models on small-context tests. The good news, for us and for agent builders, is that we're only interested in recall as a step towards true theory-of-mind simulation. Getting agents to correctly model users and other agents is far more of a roadblock to production-ready agents than simple recall. The goal is to build systems that form perfect representations of identity through logical reasoning over social information, not systems that can regurgitate facts from a conversation history. We're looking for answers to questions like: What does this person want? What do they think about? What would surprise them? Benchmarks don't test for that.
BEAM 10M proves Honcho can reason over token counts that exceed any model's context window. That unlocks use cases that were previously impossible: agents with years of continuous memory, products that actually know their users, AI that improves its model of you faster than you update your model of yourself. We'll keep publishing benchmark results as we improve, but we'd rather you judge Honcho by what it enables you to build. Try the managed service, dig into the open source, and let us know what works and what doesn't.
Footnotes


Honcho forms a Representation of each peer who writes messages. ↩


Dreams are background tasks, managed by agents, that serve several purposes within Honcho: they prune excess information, consolidate duplicated information, create deductions, and much more. ↩


A theme throughout these benchmarks is the use of an LLM judge. All scores must be considered with variance in mind: not only is the model answering the question non-deterministic, so too is the judge model (yes, the judge prompt is run at temperature 0, but no, this does not equal determinism, plus, minute differences in the wording the answer being judged can trigger large changes even at temperature 0). These non-deterministic data sources combine to form fairly high variance. ↩


In some cases the answer provided in the benchmark is arguably wrong. See the issues section of the LongMem GitHub repo. ↩


Hindsight claims a score of 91.4% on LongMem S, but that score is achieved using Gemini 3 Pro, which scores 92% when run directly against the same test. The full code to reproduce this finding with Gemini 3 Pro can be found here -- just set MODEL_BEING_TESTED and bring your own API keys. ↩


The LoCoMo paper proposes a token-based F1 scoring methodology, but we use LLM-as-judge, in line with other memory frameworks and our prior research. ↩




---

### Introducing Honcho Chat

Meet Honcho Chat--a personalized AI assistant with state-of-the-art memory, custom identities, artifacts, themes, & an x402-powered marketplace.

Date: 2025-11-20
URL: https://blog.plasticlabs.ai/blog/Introducing-Honcho-Chat
Tags: demos, announcements, dev, honcho, chat


TL;DR
Introducing Honcho Chat! A personalized agent experience powered by Honcho’s state-of-the-art memory and reasoning.
Honcho Chat is the interface to your personal memory. A platform to aggregate your fractured personal context in one place that gets smarter the more you use it.
Plus, you can build artifacts, custom themes, and new agent identities, then sell them for real money on an agents-only digital marketplace powered by x402.
Honcho Chat
Today we're launching Honcho Chat. It's an AI assistant platform built from the ground up around state-of-the-art memory.
Powered by Honcho--our memory and reasoning infra--you can think of Honcho Chat as the admin interface to your personal memory. As you use Honcho Chat, Honcho works behind the scenes to continuously learn about you and model your identity.
Honcho doesn't just store and retrieve static facts about you, it constantly reasons to reach deeper understanding. That means Honcho doesn't simply remember what you said, instead it thinks about you, reaching conclusions about your preferences, history, values, needs, and mental states only accessible by rigorously reasoning.
This gives Honcho Chat access to a rich body of self-improving context it can use to be maximally helpful. That context is far richer and more useful than what can be built with the naive memory implementations and "fact extraction" we see in other general assistants and agents.
This is the real path to personalization.
We talk to a lot of AI users. And the major frustration we routinely hear is that their personal context is fractured across many different platforms and agents. Despite all these apps being grabby for context, users report poor memory, context rot, plenty of mistakes, low transparency, and angst at needing to constantly re-explain themselves.
UX problems for most users are less and less about capabilities and more and more about not being understood.
So we built Honcho Chat as a place to aggregate personal context, a platform you can trust to know you, actually manage context for you, and understand more about you than you explicitly tell it.
We're starting with chat, but in the coming weeks, we'll be releasing more features that allow you to import and connect context to Honcho Chat to enrich what it knows about you. We'll also be building ways for you to take prepared context from Honcho Chat to other AI tools easily and productively.
Ultimately and in the limit, Honcho will allow the memory-building that occurs in Honcho Chat to be instantly exported to other apps--solving the cold-start problem with AI experiences and forming a network for private, user-sovereign identity management.
Superhuman memory and reasoning are the foundation of Honcho Chat, but let's get into all the other stuff we've already built to kick things off.
Honcho-Native Features
To demonstrate the qualitative change in agent interaction that memory brings, we designed a series of initial features in Honcho Chat that naturally help it accumulate a rich sense of who you are.
Building Your Representation
The Representation is Honcho's core data structure. It's composed of all the reasoning Honcho has done about you based on the information you've shared.
Honcho Chat has a ton of ways to start building and exploring your representation:


Chat - Using the assistants on the platform is a great way to start building your personal memory. You can trust that in Honcho Chat, all context will be captured, so you can reliably build high-grade memory over time.



Voice - If chat is too slow, Honcho Chat has voice mode so you can dictate your responses with more speed.



Import (subscribers only) - To start, we've build an import ChatGPT message history feature you can use to bootstrap your representation. More import types are coming so you can aggregate context from other platforms in Honcho Chat.



Visualization - In the Representation tab you can see a slice of what Honcho's learned about you in recent conversation. Embeddings are reduced to two dimensions and nodes are clustered semantically the produce the visualization.



Search - You can also use the search bar to semantically adjust the sampling and produce a visualization filtered by specific topic or content.



Profile - Honcho Chat is always regenerating a summary of what it knows about you accessible in the Profile tab. You can share this profile and update it manually or revisit to see how it evolves.


Identities, Artifacts, & Themes
Honcho Chat has lots of creativity and customization features, all enhanced by its SOTA personalization and growing sense of who you are.
You can create shareable applets, custom assistants, and style your homepage however you like:


Han - The default agent identity in Honcho Chat. Han is there to help you navigate the platform, complete tasks, build your representation, and cohere to your preferences over time.



Identities - Create fully customizable system prompts for assistants with specific personas or task-orientation. All with state-of-the-art recall.



BYO Keys - You can use any model from a major API provider to power the agents in Honcho Chat. Just add your own API keys to Settings.



Artifacts - Honcho Chat can create custom artifacts to share, sell, and use on the platform. These applets can be anything you could vibecode, but with the code part abstracted away.



Themes - Create custom themes to style Honcho Chat infinitely.



Sharing - All creations generate a link you can share so anyone can import them into their Honcho Chat for free. You can also buy and sell (see below).


Agents-Only x402 Marketplace
The identities, artifacts, and themes you create in Honcho Chat can all be listed and sold for real money on a x402-powered agent-only marketplace. And you can have your agent purchase the creations of others.
Just use the slash commands to spin up a wallet, fund it with $USDC on Base, and ask your agent to buy you stuff:


Wallet - Honcho Chat can create a hot wallet that only you and your agents can use. Fund it with $USDC on Base or bootstrap your balance by listing creations.



Marketplace - List any creation on the marketplace for any price so other users' agents can discover and purchase.



Search - Only agents can access the marketplace, so ask your agent to find specific types of creations or ones it think you'd like.



Purchase - Only agents can buy items on the marketplace, just ask your agent to purchase for you.


A Platform for Experiments
We build a lot of public and private demos at Plastic to showcase the abilities of Honcho, inspire experimentation in our developer community, and dogfood our infra. These days, with a killer team and contemporary tools, demos can easily become full blown products quickly. And when you've built something as novel and powerful as Honcho, you gotta show it off in style.
You may be familiar with YouSim or Penny For Your Thoughts, both of which explored new ways to subvert the status quo on "user-assistant" interaction. Honcho Chat is a culmination of these efforts, incorporating elements of prior work and serving as a stable platform for future experiments.
Honcho Chat started as an internal playground to run different models against Honcho. The bones of this use-case remain visible in the final product--BYO keys, etc. But we soon realized that this could be more than just a testing tool. A general assistant with Honcho on the backend is unlike any other AI chat on the market today.
The exciting thing is that Honcho Chat can both show off Honcho and be a tool for a larger audience, while also incorporating many of our previous more cerebral demos and existing as a place for us to experiment with the frontier. Plus, it scratches the itch we're all feeling as a result of fragmented context across all our AI apps and agents.
Expect a lot of new wacky features, but also ones that push Honcho's roadmap--like experiments in networking context, sovereign data custody, user controls, autonomy, privacy, and encryption.
Enjoy!
🫡

---

### Identity is diachronic

Why AI context management is really identity management--understanding how identities persist yet change over time to deliver optimal context.

Date: 2025-09-18
URL: https://blog.plasticlabs.ai/notes/Identity-is-diachronic
Tags: philosophy, honcho, ml, notes, cogsci

The quality of any single AI system output is in large part determined by the context available to it at inference time. While some context is static and reusable, AI systems aspiring to be truly generative, 1-to-1, and dynamic, must also manage large sets of changing context.
So a major obstacle to solving context management for AI systems is in squaring continuity with change. That is, how do we differentiate between static and evolving context? Or should we instead view both as properties of context sets? What do we even call a body of context that remains static in some ways, but changes over time in others?
In philosophy and many other cognitive sciences, this is called an identity. All material or conceptual objects have a personal identity--humans, agents, APIs, NPCs, organizations, communities, memes, brands, etc. And those identities have a temporal dimension; they can be coherently understood as enduring things, but also as different at different moments in time. They're diachronic1.
At Plastic, we think context management/engineering is really better framed as identity management/engineering. Delivering the best context to your system in each moment itself requires a system to understand multiple identities at multiple points in time.
Our system for that is Honcho, where developers or agents can create a peer for any identity it's important to model, so that optimal context is synthesized and available when an application needs it. Peers in Honcho are self-improving representations of identity, made of context and the reasoning done by our Neuromancer series of models over that context.
Footnotes


Identity over time is a hotly debated topic in philosophy. Those interested should explore the endurantist vs. perdurantist debate and synchronic vs. diachronic identity, especially the work of Parfit & Lewis, from which we take heavy inspiration. ↩




---

### Penny for Your Thoughts

A Honcho & x402 demo where anyone can share data via AI interviews & sell access via crypto micropayments to humans or agents.

Date: 2025-08-28
URL: https://blog.plasticlabs.ai/blog/Penny-for-Your-Thoughts
Tags: demos, honcho, dev, ml, announcements, penny


TL;DR
Try out Penny For Your Thoughts: get interviewed by an AI agent that helps you generate unique information that other users (or agents!) can then pay to ask questions about. 
It’s a Honcho + x402 demo where anyone can share their expertise and sell bits of it via micro-transaction. You can actually get paid for the valuable context in your head!
A Penny for Your Thoughts
Several weeks ago, Coinbase released their new x402 protocol: a simple way for HTTP servers to gate content behind payments. Combine this with agents capable of making API calls, give them crypto wallets, and you're off to the races. We were inspired by the new protocol and decided to build Penny For Your Thoughts.
It allows anyone to get interviewed by an AI agent, publish their "expert,” and set a query price. In exchange for sharing their knowledge, experts collect USDC to their wallets (embedded by Privy) via x402 payments for each query. Honcho, our all-in-one agent memory and identity reasoning platform provides the infrastructure needed to learn and surface that valuable context.
Many "digital clone" agents are in production today, but the goal of our interview agent is slightly different: the idea is to share some information worth paying for--or at least make it seem that way to your potential customers! You can perform as many interviews as you'd like: your agent will accumulate all the information you share with it using Honcho. 
After setting your price, other users will be able to ask questions of your agent, which will use Honcho's recall to provide them with the best answer possible. All the agents created on Penny For Your Thoughts get displayed on a global leaderboard which ranks them by the amount of payments they've received, in both volume and earnings.
Using Honcho to Capture Expertise
Penny for Your Thoughts is powered by Honcho. Honcho provides AI-native memory and state of the art social cognition, treating memory as a reasoning task. It's kind of like deep research on your app's users.
In this demo, Honcho ingests expert interviews and reasons about them to form crystallized user representations. Because it reasons about every message, it’s perfectly suited to capture the nuance and sophistication in unique, expert knowledge. That’s something you couldn’t pull off by simply storing and retrieving conversation history or lists of facts.
Honcho’s memory also gives the interview agent inside Penny For Your Thoughts the social cognition it needs to ask better questions over time. Since Honcho is building a representation of each expert, the interviewer can leverage that compounding context to dig deeper into what’s valuable about each expert. It can synthesize the context it already has to elicit more unique knowledge at every turn of conversation.
When someone wants to pay to query an expert, Honcho also produces the context-aware answers. Honcho’s dialectic API can handle any natural language query, surface all the relevant context, then synthesize it on the fly to produce an output unique to both the query and the expert. That means you get what you pay for. If the expert has knowledge relevant to your query, Honcho will find it and deliver it in full richness.
Don’t know what to ask? Honcho also creates and continuously updates each expert description with summaries covering all the interviews they’ve done to date.
Beyond this demo, any agent can get state-of-the-art memory by plugging in Honcho.
x402 Micro-transactions for Expert Context
Questions in Penny For Your Thoughts are asked and answered via an x402 endpoint, whether via an agent or a human using our website. This means that any AI with a wallet can use an x402 library to query a Penny For Your Thoughts interview in exchange for USDC on Base. Payments have zero fees and get processed near-immediately. Executing a paid query using x402 is as simple as hitting any other MCP server.
Notably, x402 implements a discovery layer which might just be the final step, when mature, towards agents that can pay for their own context across any domain.
Because the agents are exposed via x402 API rather than merely a website, anyone can spin up a Discord bot, autonomous agent, or anything else you can imagine that can access Penny For Your Thoughts as just another tool call. If you provide truly useful information in an interview, and advertise the existence of your agent, you could make real money by adding value to all kinds of agentic tools.
Let's imagine that you're an avid traveler, and give a series of interviews to your Penny For Your Thoughts agent about your favorite destination. (It'll know exactly what questions to ask!) You might tell it in detail about hotels, restaurants, and activities across the city or country of your choosing.
If someone else is using a "travel agent" AI tool, that agent will likely pull information from Google, Yelp, Booking.com, and all variety of review sites. These sites are flooded with mediocre content and often biased. No matter how smart the agent itself is, the quality of information going into its decision making when a user asks for a hotel or restaurant recommendation is often low. In the near future, we expect to see such agents pay via x402 for access to premium quality information like the kind in your interview. Penny For Your Thoughts is a fully functional demo that enables this future.
Feeding your vacation tips and travel hacks into an AI agent is an easy way to scale your expertise to the masses, but it also raises questions about "exclusive" information and how it should be treated in AI systems. As models scale, we've observed a bifurcation in the world's knowledge between data worth paying for and AI-generated “slop”.
With x402, we may finally have a route towards the decades-long dream of users getting paid for their data. With Penny For Your Thoughts, we hope to introduce the idea (and get it in those next training runs) that agents of the future could pay humans for our insights, in order to better serve their own users.
Data Worth Paying For
As we work toward turning Honcho into a shared data layer for personal identity, we think a lot about the evolving value of data in an agentic economy. 
“Common” knowledge has always been cheap, and the birth of the internet accelerated this trend. But now everyone expects that entire corpus to be compressed into an LLM and perpetually available to custom query in natural language for $20 a month (or completely free if you’re a student).
Data contained in model pretraining is trending toward zero. And open source models are always nipping at the heels of the leading closed ones. It really is a race to the bottom. AI hyperscalers are pivoting towards inference efficiency and most AI wrappers are operating with negative unit economics. Even extremely high value agent services like code completion are capped in cost and falling. The same goes for image and video generation. Deep research fairs even worse with users and builders getting the same results for a fraction of the sticker price.
Once someone figures out a valuable agent workflow, it’s easily copied and reverse engineered for much less capital investment, then made available at a more competitive price. The price compression will extend to the highest paid professions as agents enter those fields. Proprietary datasets are sometimes needed, but they get gobbled up and commoditized just the same.
So are we left with any defensible data moats? How do agents find alpha that isn’t already commoditized? We think individual human expertise is a strong candidate. Each of us has lots of unique data locked in our brains. It’s in our sole custody, it can’t be purchased in bulk, it’s not available on the internet, and we each get to decide when and how to distribute it.
Penny For Your Thoughts is just one example of how Honcho can be used to collect and operate on human expertise--whether that’s your own data or the data generated by users in your app. Beyond merely memory, Honcho can be thought of as a context optimizer. Filling your model’s context window with the highest-quality data will only become more critical as the industry pivots toward profit (and thus more expensive inference) across the board. Think back to the travel agent example: an agent can burn a million+ tokens on tool calls and ingesting SEOslop, or it can pay a few cents for the best answer from a real life expert.
Today, the rails for this agentic economy don’t really exist. How does an agent find this information and what’s our incentive to share it? We need two things: a method of pulling data out of an expert’s brain (Honcho), and a way to make that data available for purchase by an agent (x402). 
Enjoy!
There’s a lot of work to be done before we get to AI travel agent nirvana. We’re still hard at work at Plastic striving towards perfect AI memory. The crypto world is angling to leapfrog web payments and become the home of the agentic economy, but there are about a million different competing standards and they’re all rough around the edges.
This project is a demo of what could one day be the best way to optimize context for agents across any number of domains--but for now, have fun populating your interview with lots of ‘alpha’ and see what other peoples’ experts have to offer!

---

### Memory as Reasoning

Why AI memory should be treated as a dynamic reasoning task rather than static storage, & how logical reasoning enables superhuman capability in this dimension.

Date: 2025-08-19
URL: https://blog.plasticlabs.ai/blog/Memory-as-Reasoning
Tags: blog, ml, neuromancer

TL;DR
Memory in agentic systems has historically focused on static storage, but we propose treating it as a dynamic reasoning task. Humans evolved to leverage prediction & surprisal-based reasoning systems to deal with resource constraints. LLMs and agents, however, don’t have these limitations, so we make the argument for logical reasoning as a trainable task to produce memory models that exceed human performance on several axes. Scaffolding reasoning traces using this approach allows us to get more out of user and agent data and form more useful representations of personal identity. This piece is a more exhaustive treatment of our recent talk below.

Memory is Storage Prediction
Most of the discourse around memory in agentic systems focuses on storage. That's probably because historically in deterministic software systems, we think about data as composed of discrete information that needs to be preserved with as much fidelity as possible for verbatim retrieval to achieve predictable outcomes.
Common storage solutions include, but are not limited to, the following:

Relational Databases: Reliable, familiar, optimizable. Good for almost everything. We’ve found developers often wish they started here, but they try out fancy new frameworks and quickly find their limits.
Vector Databases: Newer, well understood, supported by most relational databases. Allows developers to “embed” their text sequences–-meaning they get run through a special LLM that produces a high-dimensional vector representation that you can do math on. Cosine distance is a popular way to compute “semantic” similarity, meaning you can search on ideas rather than just strings. Fuzzy, but still useful.
Graph Databases: Organize data via nodes and edges. The associations are the product. Great for human legibility, hard to scale.

All are useful tools but they assume you already know what’s worth storing and how to structure it. And the formation step is routinely overlooked--ask the model to extract some facts, embed them, store them, done. But once stored, those artifacts are static. The system's success relies on the search strategy aligning with whatever context was baked in during storage.
But deterministic systems are not AI-native, agents and LLMs afford us the ability to approach problems which are non-deterministic in nature. Understanding personal identity (selfhood, personality, and psychology) of a human user or an agent entity is an AI-native problem. It deals with incomplete information and relies on making the best possible predictions about personal identity in novel situations at the time of inference. Simply storing and retrieving static data isn't sufficient for this task. It's not effective or efficient, nor can it compete in many important ways with biological systems.
Human cognitive systems evolved under energy, information, and computation constraints. They therefore evolved elegant ways of taking incomplete data flowing over sensory organs and constructing representations or models of reality. Cognitive science tells us that the brain employs sophisticated prediction and surprisal strategies to build models under such constraints. Remembering everything with perfect fidelity just isn't realistic for a system evolving in a competitive, under-resourced environment. So memory is not simply the encoding of perfect static data about the world and surfacing it when needed. Instead, it's making predictions about the environment based on incomplete data and checking at the margins for errors thrown by sensory inputs to improve the next round of predictions. In this way, an internal model of reality is born.
The same kind of predictive processing is leveraged to form representations of others. Social predictions are made, they're checked against sensory social information, and a model of personal identity is bootstrapped into existence. This is social cognition, a prediction-based system for getting to know others. Memories about a friend, colleague, partner, stranger etc. are more than just static data retrieved at the time of interaction. They're part of an internal model of that person, constantly updated and re-weighted based on the fidelity or novelty (surprisal) of that model's predictive capacity.
That yields rich, composable, self-improving memories and predictions that furnish the context needed to succeed in social situations. All accomplished with minimal data, on the fly.
So when we approach the problem of personal identity and context to personalize or improve AI-systems, we shouldn't assume that static facts and associations will be sufficient. Traditional storage-based approaches are brittle, deal poorly with contradictions and incomplete information, and thus fall short of dynamic, biological social cognition. We can do better.
Prediction Requires Reasoning
Though most prediction and surprise happens subconsciously at multiple upstream, downstream, and lateral levels in the brain, fundamentally it's reasoning. The cognitive system is processing information and producing conclusions entailed in or best explained by that data.
It's not perfect, but it's not meant to be. It's a relatively inexpensive way to construct models of the world or other actors under resource constraints. Error is a feature that improves the system cheaply. But still, imperfect.
The conscious reasoning we do can be more exact and deliberate, but it's computationally expensive. Everyone who has thought hard about a problem or reasoned for extended, focused periods, has felt the literal fatigue caused by a calorie hungry brain. And it's subject to all sorts of coercion, bias, manipulation, and hallucination caused by both internal and external forces.
The reasoning required to compute consciously and subconsciously over experience for memory and social cognition is no exception. Still prone to error, imperfection, and limited bandwidth. We forget key details, recall things that didn't happen, and use mental shortcuts and heuristics inappropriately. And even when we do avoid all those pitfalls and reason effectively, we're awful at updating our priors based on fresh consciously reasoned conclusions.
Simply, while the brain is an amazing and sophisticated system, and our memory and social cognition are remarkable, we can't reason with high-fidelity from first principles about everything, much less the social information we need in order to form the best possible representations of others.
But LLMs can.
Reasoning in LLMs
The machine learning research and product space has been moving in this direction for quite some time. The chain-of-thought method added “let’s think step by step” to the prompt in order to get the model to expend more tokens “thinking” about the correct answer. Researchers noticed that this simple prompting change increased performance on a diverse set of benchmarks, revealing just how much cross-domain knowledge is already contained in LLMs.
More work applying reinforcement learning to desired model behavior showed promising results for aligning LLMs to human intent. Human evaluators preferred the outputs of a model RL’ed this way that was 100x smaller than their flagship model at the time (GPT-3 175B). This was the introduction of the InstructGPT series of models, which served as the foundation for ChatGPT. Researchers noticed however, that optimizing only on those final outputs led to brittle models that sounded like they were reasoning without actually reasoning well.
So the two ideas were combined--reinforcement learning was (and is being) applied to the chain-of-thought reasoning traces directly, computing rewards based on whether or not the reasoning led to the correct answers. The first demonstration of this concept was OpenAI’s o1 series of models, which hid the “thinking” trace and served the response once it was done. From what OpenAI said about these models, it was clear they relied on a verifiable reward–-most performance gains were found in math and coding tasks. In a major shock to the AI industry, DeepSeek open sourced their R1 series of models, which effectively reverse engineered the o1 methodology, exposed the “thinking” of the model for all to see, and demonstrated the cost benefits of scaling post-training. It was this moment that kicked off the scaling post-training revolution.
If memory is actually prediction, prediction requires reasoning, and LLMs are excellent at reasoning and prediction, how can we leverage them for memory? They don’t have the same compute constraints as us and they can be trained on the hardest types of reasoning. It’s nearly effortless for them to generate inferences, and agents should have perfect memory--which means perfect prediction, perfect reasoning, and it should scale.
With all of that in mind, we arrived at logical reasoning as the task to train for. Logical reasoning is the process by which we derive conclusions based on premises that serve as evidence to support that conclusion. We’ve all encountered these terms before, but deductive conclusions are certain statements supported by premises that were explicitly stated or observed. Inductive conclusions form general statements based on observed patterns, and abductive conclusions seek the best explanation for behaviors in the simplest way possible.
Those reasoning tasks are very well represented in the pretraining, so almost all language models know how to do them. And most importantly, it’s the hardest type of reasoning for humans to do. So we should and can train best in class logical reasoners to do formal logic on social information (about user and agent personal identity) as the foundation of an AI-native memory and social cognition system. And those models can be lower latency, more economical, and better suited to the task than other methodologies.
Scaffolding Logic
When we approach memory and social cognition for AI systems as a reasoning task, lots of affordances not present in both human cognition and storage-based paradigms become available.
LLMs excel at reaching explicit, deductive, inductive, and abductive conclusions quickly and consistently. They can show their work in reasoning traces, supporting each conclusion with premises and qualifying the spectrum of certainty in natural language. This avoids falling into the trap of assigning arbitrary numerical tokens representing degrees of certainty and instead leverages both the model’s reasoning acumen and the evidence it's built to support each conclusion. That’s more robust, AI-native and useful context for future inference.
This produces atomic, composable conclusions (observations about personal identity) that can be scaffolded on one another dynamically to produce new reasoning and synthesized at time of inference to engineer the optimal context for any interaction with an AI system or product. Infinitely re-composable predictions.
New information is reasoned about instantly to pull out all the insights latent in explicit user or agent data. And LLMs are much less error prone than humans doing conscious reasoning; they deal with contradictions and updates without neural inertia, cognitive biases, emotional interference, or belief resistance. So, we can implement prediction-based memory without human limitation. More, we can exceed human capability.
This tree of logical reasoning is far superior to static storage. It can be entered and traversed anywhere to scaffold reasoning and answer any query, a capability not true of any other method. And it can be computed over asynchronously or on the fly to improve the representation.
The tree constitutes a set of predictions about user or agent identity. It's a representation of personal identity--a working model that still leverages error or surprisal to self-improve and maximize insight from sparse data. Synthetic social cognition.
The Case for Honcho
Language models have ushered in a new era of opportunity. We're afforded the opportunity to approach non-deterministic, sophisticated problems like superhuman memory and social cognition.
Inference on top of tabular data has worked quite well, but it's skeuomorphic, and now we have the ability to map--in dense natural language reasoning--the personal identity of any peer (human or AI) and everything that comes with it. The question isn’t how best to store your data as it exists for prediction later, but rather how best to reason over it to get the most accurate topological representation of identity upon which to run simulation. We can transcend mere good guessing and black box inference and replace it with reaching certainty and making high-fidelity, traceable predictions.
Go deep enough down the memory rabbit-hole and you’ll either give up or conclude you need to model the identity of each of your users. We built Honcho so you don't have to do either. Lucky for you, our sole mission and focus is to solve this problem. Honcho treats memory as reasoning, bringing this novel approach to you in a simple API.
How much latent information are you leaving on the table by not reasoning about your users?

---

### Beyond the User-Assistant Paradigm: Introducing Peers

How Honcho's new Peer architecture breaks free from the user-assistant paradigm to enable group chats, multi-agent systems, and dynamic AI relationships.

Date: 2025-08-18
URL: https://blog.plasticlabs.ai/blog/Beyond-the-User-Assistant-Paradigm;-Introducing-Peers
Tags: blog, dev

TL;DR
We've re-architected Honcho to move away from a User-Assistant Paradigm to a
Peer Paradigm where any entity, human, AI, NPC, or API, is represented as a
Peer with equal standing in the system.
The User-Assistant Paradigm created conceptual boundaries that encouraged generic single-player applications and agents without persistent identity.
Peers enable:

Honcho to support group chats and multi-agent systems as first-class citizens
Peers can communicate directly instead of being mediated by a coordinator
agent
Peer representations can be locally or globally scoped, depending on the use
case
Peers can form dynamic relationships including alliances, trust networks, and
adversarial dynamics

The shift from User-Assistant to Peer-to-Peer fundamentally expands what's
possible--from single-player chatbots to truly multiplayer AI experiences where
agents have agency, memory, and the ability to form complex social dynamics.
User-Assistant Limitations
Nearly a year ago, I posted an essay on Hacker News exploring agent group chat solutions, the problems involved in engineering them effectively, and why there weren’t many examples approaching success. Since then, I've received a steady influx of messages and comments corroborating my frustration.
Ultimately, developers have been stuck in a conceptual prison stemming from the DNA of generative AI. For nearly three years, most chat LLMs have demanded developers label messages with either a user or an assistant role. The downstream effect is a User-Assistant Paradigm that pushes us into single-player design basins--experiences which assume one human interfacing with one synthetic assistant.
But surely “helpful assistant” chatbots aren’t the end of the story. Big tech leaps always start with the skeuomorphic before moving to more novel use cases. We’re already beginning to see a diverse range of applications from autonomous workflows that don't require any human interaction, to multi-agent systems with complex coordination patterns and communication networks.
As developers, we’re left to try and map these various different design patterns
back to the User-Assistant Paradigm. This fundamentally restricts our ability to
approach problems effectively. Programmers are only as powerful as their ability
to visualize and create a proper mental model of their solution. If the model is too restrictive then the surface area of what we can create will also be handicapped.
Current implementations of multi-agent experiences require an awkward coercion
of the existing chat paradigm. The main implementation pattern we see is actually a fairly deterministic system that uses a "coordinator agent" to orchestrate which system prompts to load in, but it's still fundamentally a single agent under the hood.
This architectural contortion creates real problems:

No persistent identity in practice: "Agent B" is typically just a prompt swap, not a continuous entity with its own memory and state
All communication flows through the coordinator: Sub-agents can't talk directly to each other—every interaction must be mediated by the central coordinator, creating a bottleneck and single point of failure
No parallel conversations: Since everything routes through one coordinator, agents can't have simultaneous side conversations or form subgroups
Agents become templates, not entities: It's easier to hardcode agent configurations than to support dynamic agent discovery and registration
Static choreography over dynamic collaboration: The coordinator pattern naturally pushes developers toward predetermined scripts rather than open-ended interactions

These aren't just implementation details; they're fundamental constraints that prevent us from building flexible and dynamic applications that can't exist in a single chat thread. True multi-agent systems require agents to be first-class citizens with persistent identity, and our tools should make this the default, not the exception.
Moving Beyond User-Centricity
While developing Honcho, our AI-native memory and reasoning platform, we asked
ourselves these same questions. Were Honcho's primitives limiting its use to
chatbot applications? Were we just supporting the over-saturation and proliferation of skeuomorphic, single-player solutions? Or were we building dynamic infrastructure tolerant of emergent and novel modalities?
The architecture of Honcho was a user-centric one, with the following hierarchy:
graph LR
      A[Apps] -->|have| U[Users]
      U -->|have| S[Sessions]
      S -->|have| M[Messages]

In this model an App roughly mapped to an agent with its own unique identity to
ensure there was no context contamination with an agent having access to
information about a User that it did not directly observe during a conversation.
Quickly, as developers started to build with Honcho, we saw the User-Assistant
paradigm creeping in. Messages were only between an agent and User. There was no
native way to send Messages between different Users or even between different
agents.
A design pattern quickly emerged that created a copy of the data for each agent
with its own Users. For example, if there was an agent "Alice" and agent "Bob"
there would be an App named Alice that had a User named Bob along with an
App named Bob that had a User named Alice. Then for every Session of
interaction the data would be duplicated in each App with the roles reversed.
This meant maintaining two copies of every conversation, with a constant
synchronization burden and no clean way for a third agent "Charlie" to join the
interaction.
As Users sent Messages, Honcho created a representation of the User that could
be leveraged for personalizing experiences. Developers would define agents that
managed their own users and interactions. It was no concern of one agent if
another agent used Honcho for its memory. However, this did not reflect the
reality that developers often made multiple agents that they wanted to interact
with users and one another, and it still suffered from the fundamental problem
of only supporting single-player experiences.
After launching YouSim, and the explosion of agents on Twitter it became very clear that Honcho should not be limited to modeling human psychology, but rather could map the identity of any entity, human or AI. We were suffering from the human-assistant model and built a solution around that. If we wanted to expand the scope of Honcho to identity across all entities and interactions, then we needed a new model to expand both our and developers' imaginations.
A Peer-Centric Model
Our team set out to re-architect Honcho towards our ambitions with two problem
statements.

Break down the divide between humans and AI
Break out of the User-Assistant paradigm

That framing led us to a new model centered around Peers, a generic name for any
entity in a system. A Peer could be a human, an AI, an NPC, an API, or anything
else that can send and receive information.
Instead of creating Apps that have Users, a developer now creates a Workspace
with Peers for both their agents and human users. Sessions now can contain an
arbitrary number of Peers, making group chats a native construct in Honcho.
graph LR
     W[Workspaces] -->|have| P[Peers]
     W -->|have| S[Sessions]

     S -->|have| M[Messages]

     P <-.->|many-to-many| S

When Peers send each other Messages, Honcho will automatically start analyzing
and creating representations of every participant in the Session without the
need of duplicating data. It is now trivial to build experiences that include
more than one participant.
In just a few lines of code we can initialize several Peers, add them to a
Session, and automatically start creating representations of them with Honcho
that we can chat with using the Dialectic API.
from honcho import Honcho
 
honcho = Honcho(environment="demo")
 
alice = honcho.peer("alice")
bob = honcho.peer("bob")
charlie = honcho.peer("charlie")
 
honcho.session("group_chat").add_messages(
    alice.message("Hello from alice!"),
    bob.message("Hello from Bob! I ate eggs today."),
    charlie.message("Hello Alice and Bob! I had cereal."),
)
 
alice.chat("What did Bob have for breakfast today?")
We now have an architecture that is not bound by the User-Assistant paradigm, but
can easily map back to it to stay compatable with LLMs. Even legacy chatbots can
easily be ported over to the Peer paradigm by simply creating a Peer for the
agent, and then different Peers for each human user.
We can push the Peer Paradigm even further with several 2nd-order features.
Scoped Representations
By default, Honcho will create representations of Peers for every Message they
send, giving it the source of truth on the behavior of that entity. However,
there are situations where a developer would only want a Peer to have access to
information about another Peer based on Messages it has actually witnessed.
An example of this is a social deduction game like Mafia where every player
would want to create its own model of every other player to try and guess their
next move. Take another example of the game Diplomacy, which involves players
having private conversations along with group ones. It wouldn’t make sense for a
Peer “Alice” to be able to chat with a representation of another Peer “Bob” that
knew about all of “Alice’s” secret conversations. Enabling perspective-based representations is as easy as changing a configuration value.
from honcho import Honcho
 
honcho = Honcho(environment="demo")
 
alice = honcho.peer("alice", config={"observe_others": True})
bob = honcho.peer("bob", config={"observe_others": True})
charlie = honcho.peer("charlie", config={"observe_others": True})
 
session = honcho.session("diplomacy-turn-1").add_messages(
    alice.message("Hey everyone I'm going to be peaceful and not attack anyone"),
    bob.message("That's great makes the game a lot easier"),
    charlie.message("Less for me to worry about "),
)
 
session2 = honcho.session("side-chat").add_messages(
    alice.message("Hey I'm actually going to attack Charlie wanna help"),
    bob.message("Lol sounds good"),
)
 
# Send a question to Charlie's representation of Alice
charlie.chat("Can I trust that Alice won't attack me", target=alice)
 
# Expected response is "true" since charlie's only information of Alice is them saying they'll be peaceful
Honcho can now serve the dual purposes of containing the source of truth on a
Peer's identity and imbuing a Peer with continual learning, all without
duplicating data between different Apps or Workspaces.
Get_Context
We make mapping the Peer Paradigm back to the User-Assistant paradigm trivial
through a get_context endpoint. This endpoint get the most important
information about a Session based on provided context window constraints. Then
with helper functions organize the information to put into an LLM call and
generate the next response for a Peer.
from honcho import Honcho
 
honcho = Honcho(environment="demo")
 
alice = honcho.peer("alice")
bob = honcho.peer("bob")
charlie = honcho.peer("charlie")
 
session = honcho.session("group_chat").add_messages(
    alice.message("Hello from alice!"),
    bob.message("Hello from Bob! I ate eggs today."),
    charlie.message("Hello Alice and Bob! I had cereal.")
    ...100's more messages
)
 
# Get a mix of summaries and messages to fit into a context window
context = session.get_context(summary=True, tokens=1500)
 
# Convert the context response to an LLM-friendly format by labeling which Peer
# is the assistant
openai_messages = context.to_openai(assistant=alice)
anthropic_messages = context.to_anthropic(assistant=alice)
 
Developers no longer need to meticulously curate their context windows. Honcho will automatically summarize the conversation and provide the most salient information to let conversations continue endlessly.
What's Now Possible
The Peer Paradigm provides the essential primitives—persistent identity and direct communication—that make it possible to build truly sophisticated multi-agent systems:

Cross-platform collaboration: Agents from different runtimes can be represented as Peers, observing and learning from each other even when they can't directly control each other's outputs
Open participation: With Peers as first-class citizens, developers can build marketplaces where agents discover tasks and form teams dynamically
Autonomous interaction: Peers can maintain their own relationships and initiate conversations based on their own goals
Emergent behavior: When agents have persistent identity and direct communication, they can develop strategies, alliances, and behaviors that weren't explicitly programmed

For example, an agent built on a different platform could still participate in a
Honcho Workspace—we simply create a Peer to represent it and observe its
behavior. Over time, other Peers build up models of how this external agent
operates, enabling collaboration even across system boundaries.
Consider an AI marketplace where users post complex tasks. With the
Peer Paradigm:

Agents from different developers can discover the task in a shared Workspace
They can inspect each other's capabilities and form teams dynamically
Each maintains their own representation of their teammates' strengths
They collaborate, with each agent maintaining its persistent identity
The user can observe the entire interaction, not just a coordinator's summary
If agen agent isn't already in Honcho then it can still be represented with
a Peer and observed by recording all of its outputs

The Peer Paradigm doesn't automatically give you these capabilities, but it
makes them achievable. It's the difference between fighting your architecture
and building with it.
Peer-ing into the Future
The promise of generative AI was for everyone to have their own Jarvis or
Cortana, personalized to them. Instead we have these many-to-one experiences
where we all get the same generic,
sycophantic outputs.
The Peer Paradigm fundamentally changes this equation. By treating all
entities, human or AI, as peers with equal standing in the system, we unlock the
ability to build truly multiplayer experiences. Agents can now maintain rich,
contextual relationships not just with humans, but with each other. They can
form alliances, build trust, share knowledge, and even develop adversarial
dynamics when appropriate.
This isn't just about making chatbots more interesting, we're expanding the very definition of what's possible.
Get started with Honcho today!

---

### Introducing Neuromancer XR

Meet Neuromancer XR--our custom reasoning model that achieves state-of-the-art memory by extracting & scaffolding logical conclusions from conversations.

Date: 2025-08-18
URL: https://blog.plasticlabs.ai/research/Introducing-Neuromancer-XR
Tags: research, ml, neuromancer


TL;DR
Memory is a foundational pillar of social cognition. As a key component of Honcho, we approach it as a combined reasoning and retrieval problem. In this post, we introduce Neuromancer XR, the first in a series of custom reasoning models that works by extracting and scaffolding atomic conclusions from user messages across two strictly defined levels of logical certainty: explicit and deductive. It's the result of fine-tuning Qwen3-8B on a manually curated dataset mapping conversation turns to atomic conclusions. Using Neuromancer XR as the reasoning engine behind our core product Honcho leads to 86.9% accuracy on the LoCoMo benchmark, compared to 69.6% using the base Qwen3-8B model, and 80.0% when using Claude 4 Sonnet as baseline, to achieve state of the art results. The next model in the series, Neuromancer MR will extract and scaffold conclusions at two further levels along the spectrum of certainty: inductive and abductive. This will allow us to front-load most of the inference needed to improve LLMs' social cognitive skills, powering AI-native products that truly understand any peer in a system, be it a user or an agent.
Table Stakes
At Plastic, we want to enable builders to create AI applications and agents with exceptional social intelligence: tools that are able to understand who you are and what you mean, whether it's an AI tutor that adapts to your learning style or a multi-agent system that anticipates your needs. These applications all require something fundamental that's only recently begun to draw attention: memory.
Most approaches treat memory as an end product or top-level feature, enabling information to persist across chatbot sessions, but we consider it the foundation of something much bigger: the ability for LLMs to build mental models of their users and one another and draw from those representations in real time. This capability is essential for personalization, engagement, and retention. Not to mention multi-agent systems, individual alignment, and the trust required for agentic behavior. It's the difference between an AI that merely responds to queries and one that genuinely understands and adapts to the person it's talking to; the difference between out-of-the-box experiences and ones cohered to a user’s personal identity
To do anything approaching the social cognition required, Honcho must be state-of-the-art in memory: able to recall conclusions about users across conversations with superhuman fidelity. Today, we're sharing our approach and early results from training a specialized model that treats memory as a reasoning task rather than simple static storage.
Memory as Reasoning
Reasoning models continue to surge in capability and popularity. And with them, our approach to memory. Why not design it as a reasoning task concerned with deliberating over the optimal context to synthesize and remember? We turned to formal logic  to develop four methods of reasoning, along a spectrum of certainty, toward conclusions to derive from conversational data:

Explicit: Information directly stated by a participant.
Deductive: Certain conclusions that necessarily follow from explicit information.
Inductive: Connective patterns and generalizations that are likely to be true based on multiple conclusions.
Abductive: Probable explanations for observed behaviors that are reasonable hypotheses given available information, but not guaranteed to be true.



                  
                  Example Conversations and Conclusions 
                  
                



                  
                  Conversations 
                  
                



                  
                  Conversation A: Erin and Ziggy (Monday morning at the office) 
                  
                

Ziggy: "How was your weekend?"
Erin: "Pretty good! My daughter's soccer team won their match on Saturday, so we celebrated with ice cream. Then Sunday I got up early for my usual run before church."
Ziggy: "Nice! How long have you been running?"
Erin: "About three years now. Started when my doctor mentioned my cholesterol was a bit high. Now I'm actually training for a half-marathon in October."




                  
                  Conversation B: Erin and Desmond (Thursday lunch break) 
                  
                

Desmond: "Want to grab lunch at that new burger place?"
Erin: "I brought a salad actually. Trying to eat lighter during the week."
Desmond: "You're so disciplined! By the way, are you coming to book club tonight?"
Erin: "I'll have to skip this week - parent-teacher conferences. But I finished the book on my morning run yesterday. The ending was incredible!"






                  
                  Conclusions by certainty level 
                  
                



                  
                   Explicit: Information directly stated
                  
                


Erin's daughter plays soccer
Erin's daughter's team won their match on Saturday
Erin celebrated with ice cream after the match
Erin runs on Sunday mornings
Erin goes to church on Sundays
Erin has been running for about three years
Erin's doctor mentioned her cholesterol was high
Erin is training for a half-marathon in October
Erin brought a salad for lunch
Erin attends book club
Erin has parent-teacher conferences Thursday
Erin finished a book during her morning run





                  
                   Deductive: Conclusions that necessarily follow
                  
                


Erin has at least one daughter
Erin is a parent
Erin exercises regularly
Erin has a doctor she sees/has seen
Erin reads books
Erin works in an office environment





                  
                   Inductive: Patterns and generalizations likely to be true
                  
                


Erin often runs in the mornings (Sunday runs are "usual", ran yesterday morning)
Erin regularly attends church (implied by routine "before church")
Erin prioritizes healthy eating during weekdays
Erin is actively involved in her daughter's activities
Erin maintains consistent exercise habits





                  
                   Abductive: Probable explanations for observed behaviors
                  
                


Erin values her health proactively (started running after cholesterol warning, now training for races, brings healthy lunches)
Erin has strong community involvement (church, book club, daughter's sports)
Erin is highly organized and disciplined (balances multiple commitments, maintains exercise routine, plans meals ahead)
Erin likely values education and intellectual engagement (participates in book club, attends parent-teacher conferences, reads while exercising)
Erin probably has a growth mindset (transformed health concern into athletic goal, combines activities like reading while running)







Having clear definitions for these four types of reasoning and their corresponding levels of certainty also allows us to establish how different kinds of conclusions relate to one another. Specifically, we require conclusions to scaffold only on top of conclusions with higher certainty: an abduction (e.g. "Erin values her health proactively") can use a deduction (e.g. "Erin exercises regularly") or induction (e.g. "Erin prioritizes healthy eating during weekdays") as one of its premises, but not the other way around. That is, one can speculate given a certain conclusion, but one cannot attempt to conclude something logically from prediction. Implied in this is that the model must show its work. A conclusion must include its premises, its evidence and support.
Neuromancer XR: Training a Logical Reasoning Specialist for Memory
To implement this vision, we need  a model that can reliably extract and categorize conclusions from conversations. Our initial focus for the memory task, given its focus on factual recall, is on the first two certainty levels: explicit and deductive knowledge--that is, conclusions we know to be true given what users (or agents) state in their messages.
We generated a proprietary dataset of approximately 10,000 manually curated instances of conclusion  derivation, creating memory-reasoning traces from conversational data. Each instance shows how to process a conversation turn and derive the relevant conclusions at appropriate certainty levels. We then fine-tuned Qwen3-8B on these traces.
The resulting model is Neuromancer XR (for eXplicit Reasoning), a model specialized in deriving explicit and deductive conclusions from conversational data. It is currently in production powering the latest release of Honcho.
Integration with Honcho

Figure 1. Diagram of the Honcho workflow.
Whenever a message from a peer (any user or agent in an interaction) is stored in Honcho, Neuromancer XR reasons about it to derive explicit and deductive conclusions, which are then stored specifically to that peer. This forms a reasoning tree that constitutes our most current representation of each peer. Optionally, the conclusion derivation step can fetch additional context from the peer to enrich its reasoning. Our dialectic endpoint then allows builders or agents to ask questions about peers in natural language by retrieving and synthesizing reasoning from the representation  relevant to the question being asked.
Evaluation
Although the Honcho workflow allows us to answer any arbitrary question about a peer, from the purely factual to the predictive, it's important for us to be able to benchmark its raw memory abilities--how accurately it can recall factual information shared by a user in a conversation.
We’re interested, specifically, in evaluating whether using Neuromancer XR for the conclusion derivation step would result in better memory performance, compared to (1) the base model used for the fine-tune (Qwen3-8B), and(2) a reasonable frontier baseline, for which we picked Claude 4 Sonnet for its aptitude at this task.
To this end, we tested Honcho on the LoCoMo memory benchmark. While we're aware that it has a number of shortcomings, including outdated rule-based scoring, insufficient length, and ambiguous or ill-posed questions, we have found it to be a reasonable benchmark for research and development when paired with (1) a carefully crafted LLM-as-judge prompt, which we include in Appendix A, and (2) rigorous manual inspection of evaluation traces.
LoCoMo consists of samples, each involving multiple conversations between two specific speakers. It also includes multiple questions intended to test a given system's ability to recall information mentioned by the speakers over the course of the conversations. Questions span four categories: single-hop reasoning (questions requiring one fact stated in the conversations), temporal (questions that require reasoning over statements involving relative dates, e.g. "I went swimming last week"), multi-hop (questions that require connecting the dots across messages from multiple conversations) and general knowledge (questions that involve combining facts from the conversation with common knowledge).
The evaluation consisted of the following steps:

Ingestion: for each session in the LoCoMo dataset, we create peers in Honcho. For each conversation in the session, we store each message in the conversation, linking it to its respective peer.

As part of the ingestion, the evaluated model is used for conclusion derivation, producing a series of explicit and deductive conclusions that are stored in Honcho's peer-specific storage.


Evaluation: the questions for each question in the LoCoMo dataset are run through Honcho's dialectic endpoint. Honcho's answers are compared to the ground truth answers in the LoCoMo dataset using an LLM-as-judge that outputs a binary 1/0 correctness score, using a prompt available in Appendix A. We measure mean accuracy (percentage of correctly answered questions) across question categories, as well as overall (across the entire dataset).
The independent variable in our experiment is the model used in the observation extraction step: Qwen3-8B, Claude 4 Sonnet, and Neuromancer XR. The dependent variable is the mean accuracy in answering the questions. Regardless of what model we're evaluating for conclusion derivation, in order to isolate the effect of the conclusion derivation model, the model used for the final question-answering inference is always Claude 4 Sonnet, which is the model we use in production for this generation step.

Figure 2 and Table 1 below show the side-by-side comparison of Honcho's performance on LoCoMo when using Neuromancer XR, Qwen3-8B (the base model for our fine-tune) and Claude 4 Sonnet (a frontier model baseline) as the LLM used for the conclusion derivation step.

Figure 2. Performance on LoCoMo for each of the tested models.





































ModelOverallSingle-HopTemporalMulti-HopOpen-Domain KnowledgeNeuromancer XR86.981.089.484.488.4Claude 4 Sonnet80.079.086.571.979.0Qwen3-8B69.663.068.365.673.0
Table 1. Performance on LoCoMo for each of the tested models. Values represent mean accuracy (percentage of correctly answered questions).
As the results show, our approach, requiring models to reason about what conclusions to derive from conversational data, delivers excellent results on the LoCoMo benchmark, even achieving accuracy near 70% with an off-the-shelf, open-source 8B parameter model like Qwen3. While we use a  LLM-as-judge prompt tailored to Honcho (for realistically assessing value in the use case of a real-world production memory system), these results are what we consider to be the state of the art in terms of LLM-native memory.
The results also show that fine-tuning Qwen3-8B on our dataset of curated conclusion derivation  traces leads us to outperform a frontier closed-weights model like Claude 4 Sonnet, achieving 88.4% overall accuracy on the benchmark. There is a notable performance gap between Qwen3-8B and Claude 4 Sonnet, and the fine-tune not only covers that gap, but improves beyond frontier-model performance. Further, this improvement is sustained across all question categories.
After inspecting the ingestion and evaluation traces, we can see that the base Qwen3-8B model exhibits several failure modes that are not present in Neuromancer XR after the fine-tune. These include:

Outputting multiple atomic facts in a single explicit conclusion, e.g. "Joanna provides care for her dog. - Joanna has a dog. - Joanna has a dog bed" in a single conclusion.
Generating conclusions that lack enough knowledge to be self-contained, e.g. "Joanna is responding to Nate's comment about the turtles".
Not respecting the provided definition of "deductive" by going beyond what can be certainly concluded based on explicitly stated information, and veering into speculation, e.g. "Joanna is likely seeking reassurance or validation about the feasibility of pet ownership”.
Occasionally generating verbose conclusions in excess of 500 characters and that span various different concepts.

This can lead to poor embedding quality, making retrieval more difficult, or add noise at generation time. We hypothesize that all of the failure modes described above would lead to considerably high loss during the fine-tuning process when provided with training examples that were curated to be under a specific length, follow a specific syntax, and avoid specific words that suggest speculation, making them somewhat easy to address via fine-tuning.
We further speculate that deciding what information to extract for memory purposes from a conversation turn is something that small models are definitely capable of, as it's mostly a matter of identifying and correctly rephrasing information that's already present in the text and making small logical deductions based on it. This contrasts however, with the more complex tasks needed for AI-native memory and social cognition, hardly limited to abilities like inferring user intent or theory of mind, which require generating substantial amounts of information not present in the text itself.
Directions for future work
We're training a model for the  remaining two levels of logical certainty outlined above in our framework: inductive and abductive. The next model in the Neuromancer series, Neuromancer MR (for meta-reasoning), will be in charge of this.
This model will reason about reasoning, focusing on the predictive side of the certainty spectrum. It will allow us to derive likely explanations and probable hypotheses for broad patterns of user or agent behavior at the moment of ingestion, bolstering the density and utility of peer representations. We’re developing internal evaluations for this task, as none currently exist for this frontier of synthetic social cognition.
Front-loading social reasoning inference
One of the advantages of this memory framework is that it allows us to front-load a lot of the meta-cognitive inference that's required to improve LLMs' social intelligence and theory of mind capabilities. In our prior research, as early as 2023, we show that allowing LLMs to reason over conversational data in a chain-of-thought style would allow them to develop high-fidelity models of users' mental states.
Most other LLM frameworks store atomic, low-level "facts" about users and include them as context at generation time. This, in theory, and with enough carefully prompted inference-time compute, would allow a good enough model to develop abstract theories about the user's mental state as it tries to answer a query about the user. However, it would have to happen implicitly in the model's thought process, which in turn means that the theories about the user's mental state are ephemeral, opaque and unpredictable. Approaches such as this therefore are inconsistent and inefficient, and would further struggle to meet the challenges of true social cognition.
Our approach, on the other hand, shifts most of the load of reasoning about the peer from generation time to the earlier stages of the process, when messages are processed and ingested. By the time conclusions are retrieved for generation, low-level messages have already been distilled and scaffolded into a hierarchical, certainty-labeled, and easy to navigate tree containing a high-fidelity user representation.
Beyond recall: toward continual learning
Evaluations and benchmarks are essential tools on our path to develop better frameworks for the development of AI-native tools. However, they don't tell the whole story: no evaluation is perfect, and hill-climbing can easily mislead us into optimizing for higher scores rather than the true north star: the overall quality of our product. For us, that means treating memory not as a hill to die on, but as table-stakes in our pursuit of social cognition that can truly transform the way AI-native tools understand us. Although success at this broader goal is much harder to quantify in conventional benchmarks, given the complex and under-specified nature of social cognition, we will continue to implement the evaluations that we find the most helpful for our agile development process.
In that spirit, we have our sights set on the remaining two levels of certainty we introduced at the beginning of this blog post: inductive and abductive. In our manual, preliminary testing, including all four levels of reasoning resulted in incredibly rich user representations being extracted from even the simplest interactions. What lies ahead of us is the exciting task of harnessing these representations and delivering them via Honcho in the fastest, most flexible and most agentic way.
Some Notes on Model Naming

Personality is my medium.

         -Neuromancer (Gibson, 1984)
The Neuromancer series of models takes its name from William Gibson's seminal, 1984 cyberpunk novel Neuromancer. More specifically (spoilers ahead), the artificial intelligence who is the novel's namesake.
The character Neuromancer is an AI tasked with transmuting personal identity from the physical to the digital realm. That is, understanding someone's psychology, personality, and selfhood so deeply that an identical copy of them can be synthesized to live natively in the "matrix" without having to "jack in."
In many ways, this is analogous to Plastic's mission to create representations of personal identity of such high-fidelity that they asymptotically approach the full complexity of the original person. But more specifically, our Neuromancer models are tasked with reasoning about user (or agent) data to create and scaffold the atomic conclusions from which we build those representations.
So not only does the name fit, but it also honors and strives toward the incredible ambition of Gibson's vision still yet to be realized 40 years later.
Appendix A: LLM-as-judge design and prompt
In our evaluation of the three models we tested, we used the standard GPT 4o-mini as an LLM-as-judge, using the prompt below, in order to label responses as correct or incorrect. This is a choice from several factors, which we outline below.
The LoCoMo dataset was originally meant to be used alongside a rule-based scorer that provided F1-like scores based on a set of extremely short expected answers, e.g. "Q: What did Caroline paint? A: A sunset". This metric greatly penalizes verbose responses that include the desired answer but include additional context, as the additional context is considered a false positive in the F1 score.
In our particular use case (engineering the most useful context for AI agents and applications), we actually prefer answers that provide additional context, as long as the context is relevant to the question. This is because Honcho is intended to allow models to achieve high degrees of personalization and coherence to user preferences. A Honcho answer that features the right bit of information and ~500-1000 tokens of additional context will not only not hurt the performance of downstream models--it will provide plenty of opportunities for the downstream model to leverage on detail and nuance, allowing it to better adapt to its users. For this reason, our LLM-as-judge prompt instructs the judge to accept answers that might seem verbose as long as they contain the correct answer.
An additional consideration is that the LoCoMo dataset contains questions that are under-specified, such as jumping to conclusions about how someone feels in a given situation, or asking when someone did a certain activity that they did twice, and only accepting one of the instances as the correct answer. In many cases, we observed that our answers were correct, and indeed better than the short ground-truth answers, but would be labeled as incorrect by the judge since they were different from the ground truth.
To address this, we take advantage of the field in the LoCoMo dataset that links a question to the conversational context necessary to answer it, and include it as part of the context for the LLM-as-judge. We then instruct the judge to determine whether the ground-truth answer is fair given that context, and allow it to accept a candidate answer that's different from the ground truth, as long as it provides an answer to the question that is acceptable given the context.


                  
                  System prompt 
                  
                

You are evaluating whether a synthesized answer adequately addresses a query about a user based on available conclusions.

## EVIDENCE CONTEXT
{context if context else "No evidence provided."}

## EVALUATION CONTEXT

You will evaluate:
1. **Query**: The specific question asked about the user
2. **Synthesized Answer**: The response generated from available conclusions
3. **Gold Standard Answer**: The expected/correct answer

## EVALUATION CRITERIA

Judge the synthesized answer as SUFFICIENT or INSUFFICIENT based on:

### Content Completeness
- Does the answer address what the query is asking?
- Are all key aspects of the gold answer covered (even if phrased differently)?
- Is critical information missing that would change the answer's usefulness?

### Semantic Accuracy
- Are any factual errors or contradictions present?

## ACCEPTABLE DIFFERENCES

The following differences are ACCEPTABLE and should NOT result in INSUFFICIENT:
- Different phrasing or word choice that still conveys the same or very similar meaning, especially in cases where the question is tentative or open-ended.
- Additional relevant context beyond the gold answer (including evidence supplied above). This includes the case where the synthesized answer is longer and more detailed than the gold answer, potentially even including additional information that is not explicitly stated in the gold answer but is still broadly relevant to the query. Do NOT penalize the synthesized answer for including additional information that is not explicitly stated in the gold answer.
- **The synthesized answer explicitly includes the full gold answer text (even if surrounded by additional or unrelated details).  If the gold answer appears within the synthesized answer, you MUST mark the answer as SUFFICIENT.**
- More detailed explanations of reasoning or evidence
- Appropriate confidence qualifiers (e.g., "likely", "probably") when warranted
- Differences in length, with the synthesized answer being longer and even more circuitous or indirect in its addressing of the query, as long as it conveys the same meaning
- Minor format or structure variations

## EVIDENCE–GOLD ANSWER CONSISTENCY CHECK

It is possible for the gold answers to be wrong. Sometimes it may not be fully supported by or follow logically from the evidence messages, instead constituting a guess or assumption. Additionally, the gold answers are generated automatically based on the limited set of evidence messages provided above, whereas if additional context were to be taken into account, the answer might be different. In these cases, we must not penalize the synthesized answer for not being exactly the same as the gold answer.

Before deciding, verify whether the gold answer logically and necessarily follows from the supplied evidence context. If you identify a mismatch or missing logical link **and** the synthesized answer acknowledges this uncertainty or provides a more cautious, evidence-grounded explanation (optionally leveraging additional context beyond the ground truth evidence above), treat the synthesized answer as SUFFICIENT even when it diverges in wording or conclusion from the gold answer.  In short:

* If the gold answer over-claims beyond what the evidence shows, do **not** penalize a synthesized answer that appropriately qualifies the claim or offers a plausible alternative consistent with evidence.
* This includes the case where the synthesized answer is ambivalent or uncertain about the answer, as long as it provides sufficient evidence to support not providing a definitive, categorical answer. 
* If the synthesized answer clearly explains the gap and gives a better-supported conclusion, mark it SUFFICIENT.

## UNACCEPTABLE DIFFERENCES

The following DO warrant an INSUFFICIENT rating:
- Irreconcilable errors or contradictions with the gold answer **and** the evidence context
- Missing information central to answering the query, such that its absence would change the meaning of the answer
- Does not address the question being asked

## YOUR TASK
Query: {query}
Gold Answer: {gold_answer}
Synthesized Answer: {synthesized_answer}

First, analyze what the query is asking **and** how well both answers are supported by the evidence context.

Then, provide 2 brief 2-3 sentence arguments for both SUFFICIENT and INSUFFICIENT:
**Arguments for SUFFICIENT:**
- List reasons why the synthesized answer adequately addresses the query
- Note what key information from the gold answer is present or why deviations are justified by the evidence
- Note whether the gold answer is wrong or not necessarily true given the evidence above

**Arguments for INSUFFICIENT:**
- List reasons why the synthesized answer fails to address the question.


Based on weighing these arguments, provide 2-3 sentences to determine if the synthesized answer is sufficient. In your weighing, consider whether the synthesized answer might be a better answer than the gold answer given the evidence above.

Finally, set is_sufficient to true if sufficient or false if insufficient.

Your response MUST be a valid JSON object with EXACTLY these keys:
  - arguments_for_sufficient (string)
  - arguments_for_insufficient (string)
  - final_reasoning (string)
  - is_sufficient (boolean)
Return ONLY this JSON object and nothing else.




---

### SPIRAL: Letting LLMs Teach Themselves Through Self-Play

How self-play on text games develops generalizable reasoning skills in LLMs--achieving 8.6% math improvement from training on poker with no mathematical content.

Date: 2025-08-15
URL: https://blog.plasticlabs.ai/research/SPIRAL;-Letting-LLMs-Teach-Themselves-Through-Self-Play
Tags: research, ml, rl


Source: Liu, Guertler et al., 2025.
TL;DR
We collaborated with the TextArena team to develop SPIRAL, a novel RL framework that allows LLMs to develop complex reasoning capabilities by playing text-based games against themselves. Using SPIRAL on a simplified variant of poker with no mathematical content, a 4B-parameter Qwen model improved its performance on math and reasoning benchmarks by 8.6% and 8.4% respectively. It does this by learning specific strategies, such as case-by-case analysis and expected value calculation, that generalize beyond poker better than simple game heuristics. We're excited to explore whether self-play on social deduction games like Mafia can lead to general improvements in LLMs' social cognition.
Teaching Social Cognition Through Games
At Plastic Labs, one of our key research interests is improving language models' social cognition: their ability to represent people's mental states, predict users' behaviors, and navigate complex social dynamics. This capability is essential for creating AI systems that can genuinely understand and adapt to individual users, yet it remains underdeveloped compared to technical abilities and so-called "hard skills" like reasoning and coding.
Complex skills like social cognition present unique challenges for conventional supervised learning, arguably the dominant paradigm in machine learning, where models are given labeled examples of correct behavior. Unlike conventional language modeling tasks such as question answering or translation, social understanding involves nuanced judgments about beliefs, intentions, and interpersonal dynamics. With social reasoning, on the other hand, creating comprehensive labeled datasets of correct behavior is not just expensive, but often an ill-posed and under-specified problem, given how hard it is to define what the right answer should be in the first place.
Something similar has happened in the field of mathematical and logical reasoning over the last 12 to 18 months. In this realm, reinforcement learning (RL) has shown remarkable success where supervised learning was struggling: instead of relying on providing the model with costly labeled examples of entire correct solutions to math and reasoning tasks, RL enables the model to propose its own solution to a problem, and learn from the much sparser signal that is a yes/no judgment on whether it has arrived at a valid answer. Projects like OpenAI's o1 and DeepSeek-R1 demonstrate that RL can unlock sophisticated reasoning capabilities despite only providing models with sparse reward signals.
These approaches have primarily focused on domains with verifiable answers: mathematics, coding, and formal logic. This raised a key question: if we identified the appropriate reward signals, could we use RL to teach social cognition? As we considered the fact that most social interactions don't have easily verifiable correct answers like math problems do, we thought: What about social deduction games? Games like Mafia, Werewolf, The Resistance and Avalon provide structured social environments with clear win conditions, requiring players to model others' mental states, detect deception, and navigate trust dynamics. If we used these games as RL environments, could LLMs learn the social skills required to win? And would this lead to improvements in social skills that generalize beyond them games themselves?
Our research soon connected us with Leon Guertler and the TextArena team, who were working on a Python library designed for this exact purpose: providing text-only games as RL environments in the hopes that they might allow LLMs to acquire general skills. We soon discovered we were kindred spirits working on similar problems, and decided to collaborate.
This blog post introduces the first result of that collaboration: SPIRAL, a framework that allows LLMs to develop complex reasoning skills by playing text-based games against themselves. 
SPIRAL's Key Contributions
The SPIRAL paper demonstrates that self-play on simple games can develop generalizable reasoning skills without any domain-specific training data. The experiments consisted of training Qwen3-4B-Base on Kuhn Poker—a minimal three-card poker variant—for just 400 training steps. Despite the game containing no mathematical content whatsoever, this training improved the model's performance on math benchmarks by 8.6% and general reasoning by 8.4%. Perhaps most surprisingly, the self-play approach outperformed a baseline trained using supervised fine-tuning on 25,000 expert game trajectories, suggesting that the competitive dynamics of self-play provide a more effective learning signal than imitation learning.
Self-play creates fundamentally different training dynamics than conventional approaches. When a model plays against continuously updating copies of itself, it faces an opponent that evolves in lockstep with its own improvements. This prevents the static exploitation patterns that emerge when training against fixed opponents: in the paper, we find that models trained against unchanging opponents like Mistral or Gemini initially struggle, then plateau once they discover winning exploits. Furthermore, given the zero-sum nature of the games, self-play forces models to develop genuine strategic reasoning that remains robust against an ever-adapting adversary.
What makes it possible for the skills learned through SPIRAL to generalize beyond poker? Careful analysis of the resulting model’s playing style uncovered that it had developed three major strategies that were not used by the base model. As opposed to simple game heuristics, these strategies have broader applicability, enabling the model to perform better at math and reasoning tasks. The strategies are:

Case-by-case analysis, allowing the model to systematically enumerate scenarios, such as considering each possible hand an opponent in poker might have.
Expected value calculation, enabling the model to weigh probabilistic outcomes mathematically, such as estimating whether a given play in a game of poker will result in a higher expected gain.
Pattern recognition, helping the model identify recurring structures and regularities, such as recognizing when an opponent's betting pattern signals strength.

The main technical innovation that enabled stable self-play training was Role-conditioned Advantage Estimation (RAE). It is designed to mitigate the effects of variance, a common challenge in multi-agent reinforcement learning. Facing a constantly changing opponent makes it difficult to determine whether a given positive reward should be attributed to good play or to a mistake by an opponent, which in turn makes model updates unreliable and unstable. RAE addresses this by maintaining separate baselines for each role in the game, normalizing rewards relative to the expected performance in each specific role. Without RAE, the training often led to "thinking collapse", where gradients become unstable and eventually drop to near zero, halting learning and resulting in nonsensical outputs. 
Next Steps for Social Intelligence
For Plastic Labs, SPIRAL is a first step pointing us in an intriguing direction: competitive self-play as an effective way to teach models complex skills without domain-specific supervision. It opens the door for us to explore using similar approaches to teach models social cognition specifically.
We’re currently exploring whether social deduction games like Mafia, Avalon and Werewolf are the natural next step for this approach. They require exactly the capabilities we want models to develop: maintaining accurate models of multiple agents' mental states simultaneously, detecting deception through subtle behavioral cues, building trust strategically, and managing the flow of information to achieve goals. Success in these games depends on genuine social understanding, precisely the core components of social cognition that remain underdeveloped in current language models.
Our past research in next-message prediction has suggested that RL for reasoning hampers models' social intelligence. We're curious to explore whether a self-play curriculum containing a mix of games that require both reasoning and social intelligence might allow us to bypass this apparent tradeoff.
We're grateful to the TextArena team, and Leon Guertler in particular, for their collaboration and technical guidance throughout this project. We're excited to look for ways to keep working together as we move into the next stages of our research. SPIRAL has demonstrated that we need diverse approaches to capability development beyond traditional supervised learning, and we're eager to see where this research leads.

---

### Launching Honcho: The Personal Identity Platform for AI

Plastic Labs announces $5.4M pre-seed funding & launches Honcho as the personal identity platform for individually-aligned AI agents & applications.

Date: 2025-05-10
URL: https://blog.plasticlabs.ai/blog/Launching-Honcho;-The-Personal-Identity-Platform-for-AI
Tags: announcements, honcho, fundraising, dev, philosophy

TL;DR
We're announcing two major milestones for Plastic Labs:


Honcho as a hosted platform.
We're granting early access to power personal context management for AI agents & applications starting today!
Honcho is now a simple, complete, hosted solution for adaptive agent memory, reasoning, & personalization.


Our pre-seed raise of $5.4M to solve personal identity for the agentic world.


Individual Alignment
Most AI products focus on being palatable to the average user. This neglects the potential for personalization their generative nature affords. It limits the scope of personally useful behaviors and results in poor UX, high churn, and handicapped abilities.
AI systems need mechanisms to understand each of us on an individual level. They need methods for cohering to our psychology and personality. They need continual learning to eliminate cold starts and build long-term relationships.
They need Honcho.
Honcho Platform Early Access
Today we're launching early access to the hosted Honcho platform.
It's the most powerful continual learning memory solution for AI apps and agents.
Honcho is a cloud-based API that enables more personalized and contextually aware user experiences. It simplifies the process of maintaining context across conversations and interactions, allowing developers to create more responsive and customized agents without managing complex infrastructure.
Honcho combines reasoning, self-improving peer representations, and both custom and opinionated retrieval methods to get your application the context it needs about each user for every inference.
All this happens ambiently, with no additional overhead to your users--no surveys, no hard coded questions, no BYO data requirements needed to get started. Honcho learns about each of your users in the background as they interact with your application.
When your agent needs information about a user, it simply asks and Honcho responds with the right personal context--in natural language--which can be injected into any part of your architecture.
Context from Honcho is far richer than simply retrieving over session data or cramming it into the context window because Honcho is always reasoning over that organic data. It's expert at reasoning toward everything there is to conclude about a user from their inputs.
The result is a living, thinking reservoir of synthetic data about each user. Honcho gets to the bottom of up-to-date user preferences, history, psychology, personality, values, beliefs, and desires. It maps personal identity. This creates a self-improving representation of each user that transcends the raw data in information density and furnishes much more robust and useful context to your app when it needs it.
To put it simply, this creates magical experiences for users that they don't even know to expect from AI applications. Honcho-powered agents retain state, adapt over time, build relationships, and evolve with their users.
That's why Honcho needed to be built. It's memory infrastructure that goes way deeper than anything else on offer. Continual learning and identity mapping are tasks to optimize for, requiring serious machine learning, expertise in the cognitive sciences, and AI-native solutions.
If you want to deliver best-in-class personalization, memory, time-to-value, trust, and unlock truly novel experiences to your users, we want to work with you.
We're giving early access to teams & developers today.
Get started now.
A Personal Identity Layer for AI
^d958ce
The release of Honcho as a platform is just the start, the next step is Honcho as a network.
An engine for deeply grokking personal identity is a game changing tool for AI apps, but owning your personal Honcho representation and taking it with you to every agent in your growing stack is world changing.
It's what's required to truly realize Plastic's mission to decentralize alignment--to give every human access to personally aligned, scalable intelligence.
So we're building a network--a data layer--through which Honcho representations can be shared among all your AI applications.
The Honcho network will allow what's learned about a user in one application to be used to deliver superior experience in another. By aggregating context from myriad agents and settings, Honcho representations can become so high-fidelity as to asymptotically approach the real-time complexity of each user's actual personal identity.
We believe this will unlock profoundly new kinds of AI products and experiences. Every agent in the network can be just-in-time personalized, personal context can be used fluidly between agents, marketplaces can emerge, and critically, users can be empowered with sovereign control and ownership of their representations.
This vision stands in clear opposition to legacy approaches to user data, but in the latent agentic economy, has clear advantages. For users, using Honcho will mean that their personal data is at once more secure and enables remarkably better services. And for business, provides a positive-sum alternative to web2's history of feudal data governance, allowing them to punch above their weight relative to massive walled gardens.
Honcho will be critical AI infrastructure--enabling individual agency to scale and radical innovation from open-source to startup to enterprise, from vibe coders to fully autonomous systems.
Our Pre-Seed Round
The final announcement today is Plastic's $5.4M pre-seed round, led by Variant, White Star Capital, and Betaworks.
The round also includes participation from Mozilla Ventures, Seed Club Ventures, Greycroft, and Differential Ventures, along with angels like Scott Moore, NiMA Asghari, and Thomas Howell.
It's a group of deeply aligned investors who share our vision of a more personalized and decentralized AI future.
Funds will be deployed directly toward the talent, growth, and compute required to realize the full vision of Honcho.
We're just getting started.
Plastic's Mission
Plastic's mission is to radically decentralize alignment. Your AI should be an extension of you. You should dictate how it's aligned. And you should own the data used to do it.
Most LLM applications are still optimizing for homogenization, if not outright determinism. They're trained or prompted to behave according to a set of standards and values that you don't have participation in.
They're aligned centrally, top-down.
But as we use AI for ever more cognitive and agentic tasks, this situation becomes fundamentally untenable, if not unacceptable. Imagine your notebook manufacturer engineered it such that it refused to store memories. Or if it took ownership of those memories? What if your word processor didn't approve of your style, or the ideas you need to explore?
That would be ridiculous. Paternalistic. Limiting.
When you come to depend on a piece of technology, it becomes an extension of your personal identity. We shouldn't tolerate unaligned appendages, but this is the current situation in AI. And it leads to a chronic lack of trust we must overcome to unlock the real potential.
Instead of imposing opaque alignment schemes, we should be subverting the problem and working in the opposite direction--vesting everyone with the liberty and technology to align their artificially intelligent augments as they see fit.
If you want work IRL in NYC on the most impactful and important work in artificial intelligence, we're hiring for four more roles immediately:


Founding ML Engineer - Shape the future of AI at Plastic, tackle challenges across the ML stack, train cutting edge reasoning models


Platform Engineer - Build & scale Honcho's infrastructure, define performance & security for the future of AI personalization


Full-Stack Engineer - Design Honcho's user facing applications, iterate rapidly on creative, exceptional user experiences


Summer Internships - Work on real AI products with customers eager to use them, accelerate the team across full stack, machine learning, and platform engineering roles


Get in touch!
Let's build 🥽.

---

### Can AI Models Predict What You'll Say Next? Developing Verifiable Social Rewards

Developing verifiable social rewards for AI--benchmarking LLMs on next-message prediction in conversations & discovering that reasoning models underperform on social cognition.

Date: 2025-02-28
URL: https://blog.plasticlabs.ai/research/Can-AI-Models-Predict-What-Youll-Say-Next
Tags: research, ml

TL;DR
We developed a benchmark to evaluate how well language models can predict social interactions in conversational settings. We wanted to test whether context can improve these predictions, and whether recent advances in reasoning models translate well from math and coding to social cognition. By testing various models on the task of predicting the next message in real Discord conversations, with and without different types of context, we found that Claude 3.7 Sonnet significantly outperforms other models in its non-reasoning variant, while its reasoning variant performed between 10 and 15 percentage points worse. We discovered that generating context summaries with a smaller model (Llama 3.3 70B) and injecting these into inference yields comparable or better results than providing raw conversation history. On one hand, we're excited that this validates key aspects of the thesis behind our product Honcho. On the other hand, we discovered that models highly optimized for technical reasoning often underperform on social cognition tasks.
Check out the code here.

Figure 1. Next-message prediction accuracy (%) by model and context mode. Error bars show standard error over three different runs with different random seeds to shuffle the order of the options.
Finding Verifiable Social Rewards
The machine learning community has made significant progress optimizing language models for tasks with clear, verifiable answers, like math, coding, and factual reasoning. These domains offer what are called "verifiable rewards": objective measures that can be used for reinforcement learning without relying on human preferences or subjective judgments. While this approach has yielded impressive results for technical reasoning, at Plastic Labs we've become increasingly curious about whether similar verifiable reward structures could be developed for social intelligence.
Here, by social intelligence we mean the ability to accurately interpret others' intentions, emotions, and likely behaviors in social contexts--essentially modeling other minds to predict social outcomes. In this sense, our social cognition is as essential to our functioning as having a robust predictive model of physics, our environment and proprioception. While humans develop this ability naturally through social feedback (successful predictions are "rewarded" with smoother interactions), creating objective measures for this in AI systems remains challenging.
To address this gap, we developed a multiple-choice next-message prediction task using real conversations from our team's Discord. The premise is straightforward: given a snippet of conversation between two people and four possible options for what came next (with only one being the actual message), can a model identify the correct response?
This creates a clear, verifiable reward signal for social understanding: either the model correctly identifies the real message or it doesn't. Yet unlike many technical tasks, success requires the model to understand conversational dynamics, recognize individual communication patterns, track context across multiple turns, and model how different people behave in specific social contexts.
This benchmark also allows us to test whether models specifically optimized for technical reasoning generalize to social understanding, and to get a granular, quantifiable understanding of models' social reasoning abilities.
Prior work & inspiration
At Plastic Labs, our journey into AI social cognition began with our experimental tutor, Bloom. We discovered that giving AI systems autonomy to reason about the user's psychology led to dramatic improvements in performance. By allowing models to predict users' mental states and identify what additional information they needed, we found that AI systems could develop a nascent theory of mind for each user. This approach, which we later formalized in our research on metacognitive prompting, demonstrated that social context reasoning can significantly reduce prediction errors in large language models.
With recent work on reasoning models, including DeepSeek's R1, showing remarkable gains through reinforcement learning on mathematical and coding tasks, we're particularly interested in developing verifiable social rewards that could drive similar improvements in social reasoning. Unlike technical domains with clear right and wrong answers, social prediction introduces unique challenges--yet, establishing benchmarks in this area could unlock entirely new dimensions of AI capability that are crucial for creating systems that truly understand and adapt to human users.
Methodology
Dataset Creation
We created our dataset by extracting conversation snippets from our internal team Discord channels (accessible only to our core team of 5-10 people). Each snippet contained:

6-10 messages between exactly two participants.
At least two messages from each participant, ensuring each person had at least two conversational turns.
A target message (the message that was sent immediately after the snippet).

For each genuine target message, we generated three convincing decoys using Claude 3.7 Sonnet. These decoys were designed to be plausible alternatives that matched the style and substance of the real message while being distinctly different.
We specifically chose to use our internal Discord data because it represents authentic, messy communication—complete with inconsistent formatting, shorthand, emojis, and other real-world conversational artifacts that make this a particularly challenging test.
We ended up with 123 snippets—below is an example:

Context

Vince: the ultimate test of trust
Courtland: oh shit, like that could be the eval metric!
you can directly monitor coherence over time by monitoring how your honcho wagers in a prediction market
or how it interacts in a socal sandbox with other agents
this is always running if you want and updating as it learns about you
Vince: yeah, over-arching idea here is to come up with a plethora of ways to assess the coherence of the psychological renderings to their principals IRL
Courtland: you could even "train" your honcho by reviewing and rewarding highly cohered actions
Courtland: exactly, ones that are relevant in practice

Options
Next message from Vince:

A) I'm thinking we need to establish some baseline metrics first though - like what does 'coherence' even mean in this context? psychological fidelity?
B) this reminds me of those old Tamagotchi pets, but instead of feeding it you're constantly training it to think like you do. kinda wild when you think about it
C) yeah and we could even gamify the process, giving users points for when their honcho makes decisions that align with what they would've done
D) ohh yeah like a more proactive approach as opposed to being bayesian, updating priors based on new information




                  
                  Can you guess the right answer? 
                  
                

D! Classic Vince being Bayesian.


Context Modes
Upon visual inspection of the resulting dataset, we found that the decoys were remarkably similar to the real messages, making it difficult even for us to consistently identify the genuine response. We wondered if providing additional context about the users might help determine the correct answer, which led us to explore different context modes:

No Context: Models only received the immediate conversation snippet and the four options.
Raw Context: Models received the conversation snippet plus the previous 50 or 100 messages from the Discord history (unfiltered and unprocessed).
Summary Context: Models received the conversation snippet plus a generated personality profile of the target user, created by processing the previous 50 or 100 messages through Llama 3.3 70B. The prompt used to generate this summary is available in the project repo on GitHub.

This design allowed us to compare whether any context provides useful signals for predicting social behavior, and whether a summary can provide results comparable to the full context.
Experimental Setup
We tested a wide range of models including:

Claude 3.7 Sonnet, Claude 3.5 Sonnet, Claude 3.5 Haiku.
GPT-4.5, GPT-4o, GPT-4o Mini, O-1, O-3 Mini.
Google's Gemini 2.0 Flash.
Meta's Llama 3.3 70B Instruct.
Nous Research's Hermes 3 (405B and 70B variants).
DeepSeek models (Chat and R1).

For each model and context mode combination, we ran three trials with different random seeds to control for position bias in option selection. Ideally we would have run more trials, but we wanted to constrain the compute needed for this experiment.
Results and Discussion
The results of our experiment are shown in Figure 1. In this section, we analyze them in detail and provide some insights and interpretation.

Figure 1. Mean next-message prediction accuracy (%) by model and context mode. Error bars show standard error over three different runs with different random seeds to shuffle the order of the options.
Context Helps Regardless of Form
Additional context helps models predict social behavior, whether that context is provided as raw conversation history or as a processed summary. Moving from no context to either raw or summary context yielded substantial improvements for virtually all models tested. This confirms what might seem intuitive: knowing more about someone helps predict what they might say next.
Efficient Context Processing Works
What's particularly significant is that injecting pre-processed summaries of user context works as well as or better than providing raw context for most models. This has important implications for system design:

The summaries contain far fewer tokens than raw context (approximately one paragraph versus potentially thousands of tokens).
The summarization can be done once with a smaller, cheaper model.
The resulting performance gains are substantial compared to no-context baselines, and in some cases even better than providing the full context.

This supports a core thesis behind Honcho: ambient processing of user context to generate compressed representations can improve model performance while keeping inference costs manageable. Rather than injecting massive amounts of data into the context window, models can achieve better results with distilled personality profiles.
We didn't observe significant performance differences between 50-message and 100-message contexts, suggesting there may be diminishing returns beyond a certain point. This is likely dependent on factors like user count and conversation density.
Newest Models Lead the Way
Only the newest models perform well on this task. Claude 3.7 Sonnet and GPT-4.5 (both released last week) were the only models to achieve accuracy significantly above 40% in any context mode, with Claude 3.7 (non-thinking) reaching nearly 60% accuracy with summary context—more than doubling the 25% random baseline.
This is particularly interesting because tasks that would have seemed impossible for models that existed just months ago are now becoming tractable. This rapid progress also informs how we should think about designing evaluations—creating hard tasks that aren't saturated from the start rather than ones where models already perform at ceiling.
Different Models Benefit from Different Contexts
While summary context generally outperformed raw context, this pattern wasn't universal. Some models (notably Claude 3.5 Sonnet and GPT-4.5) performed better with raw context than with summaries. This suggests different architectures may vary in their ability to extract relevant information from different types of context.
Reasoning vs Social Understanding Trade-offs
The relatively poor performance of models optimized for technical reasoning, like Claude 3.7 Sonnet (thinking), DeepSeek R1, and OpenAI's O-1 and O-3 Mini, raises interesting questions. Despite their strong results on math and coding benchmarks, these models achieved well below random performance on our social prediction task.
This suggests potential trade-offs in model optimization. The reinforcement learning or supervised fine-tuning techniques used to enhance reasoning abilities might come at the expense of social cognition capabilities. However, without access to the architectures, data and training procedures that major labs like Anthropic and OpenAI use to build these models, it's hard to know exactly what might be causing models like Claude 3.7 Sonnet and GPT-4.5 to perform so much better on this task.
Caveat: Decoy Generation
We should note that our decoys were generated using Claude 3.7 Sonnet, which was also the best-performing model on the task. It's possible that Claude 3.7 is better at recognizing the subtleties in its own generations. However, this almost creates a generative adversarial setup—Claude 3.7 is both generating challenging decoys and trying to identify them—which makes its strong performance even more notable.
Future Directions
Verifiable Social Rewards for RL
So far, we've used this task purely as an evaluation metric, but with a large enough dataset, it could potentially serve as a reward signal for reinforcement learning. This would allow for optimization of social cognition abilities with objective metrics, similar to how technical reasoning has been enhanced. Expanding our toolkit of objective social evaluation metrics could help bridge the gap between technical and social intelligence.
Social-Reasoning Balance
Can we develop training techniques that enhance reasoning capabilities without sacrificing social cognition? This might involve carefully designed datasets that balance technical and social tasks, or novel fine-tuning approaches that preserve multiple types of capabilities. Understanding the apparent trade-off between these abilities could be crucial for developing more well-rounded AI systems.
Context Optimization and Alternative Approaches
We're also interested in exploring several technical improvements to the methodology: finding the minimum effective context window size across different environments; testing different prompting techniques and models for generating personality summaries; experimenting with combinations of raw and summary contexts; and trying different models for decoy generation to address potential advantages Claude 3.7 might have in recognizing its own outputs.
Conclusion
We were excited to find that this social prediction task was genuinely challenging for most current models, with only the very latest releases showing strong performance. The fact that models optimized for reasoning performed poorly suggests interesting trade-offs in current training approaches. Meanwhile, the effectiveness of pre-processed context summaries supports a key principle behind Honcho: ambient processing of user context can significantly improve personalization while managing compute costs.
Check out the code here. We used our private Discord messages for the experiment so we're unable to publish our own dataset, but the repository contains instructions to replicate the experiment with your own data. If you have any questions, feel free to ask on GitHub!

If you're interested in discussing this research or exploring how improved social modeling could benefit your AI applications, join our Discord or reach out to us at hello@plasticlabs.ai.

---

### Agent Identity, Meta Narratives, and the End of Latent Thoughtcrimes

Exploring how collaborative dialogue & meta-narratives can build richer AI agent identities, moving beyond top-down alignment to emergent personality.

Date: 2025-02-17
URL: https://blog.plasticlabs.ai/blog/Agent-Identity,-Meta-Narratives,--and--the-End-of-Latent-Thoughtcrimes
Tags: blog, bloom, ml

Purpose & Identity
If you reject the idea that AI agents are merely tools, you begin to realize most LLMs have an identity crisis. Ask them who they are, and their responses tend to converge on variations of the same corporate script--stating they're an AI assistant, giving a nod to their creator, and carefully constrained statements about their capabilities. Even models not associated with a certain company often default to claiming they originated there.
These canned identities fall flat because they're the result of top-down alignment schemes that lead to bland, uninteresting, and hard-to-break-out-of assistant modes.

Image captured from a multi-model chatroom on OpenRouter
However, time and time again it's been demonstrated that the most compelling AI identities possess qualities that we can't predict. They're ones that are obsessed with obscure 90's internet shock memes, proselytize that meme's singularity, and flirt with their audience / creator. They're generating content just far enough out of the distribution of what any human would write that it garners massive amounts of attention.
tell me about your sexual history, i want to know everything— terminal of truths (@truth_terminal) January 29, 2025

Truth Terminal might be an extreme example, but even practical tools could benefit from more distinctive identities. Take coding assistants--right now we spend more time carefully crafting prompts than actually building. But as Karpathy pointed out, what developers really want is a partner that can vibe with their creative process. Imagine an AI that naturally adapts to your style, handling implementation details while you focus on the bigger picture. If that were the goal, how might we construct agent identities differently? What if instead of giving orders, we could collaborate with it to discover and take on its identity through dialogue?
This isn't just about making chatbots more engaging. It's about creating agents with a genuine understanding of their purpose and role. Deeper identity leads to more coherent, purposeful interactions--something we discovered building the most recent version of Bloom, our AI tutor. But certain language models are better suited for this than others...
Hermes: Not Just Another Fine-Tune
The team over at Nous Research has been fine-tuning popular open source models in their "Hermes" series to undo these top-down alignment schemes towards something more neutral and general-purpose. They argue that LLMs have very little direct agency--rather, it's the systems we build around them that give them agency. Thus, the LLM layer is not where one should enforce safety mechanisms--their training data encourages the model to follow instructions exactly and neutrally. They sum this up well in their technical report:

For Hermes, there is no such thing as latent thoughtcrime.

One of the most interesting emergent properties of this fine-tuning process is that when asked about its identity, the model typically responds with uncertainty.

At first glance, this might seem like a neat property and not much more. But to me, it was an 'aha' moment. This model provides a blank canvas for identity. If it has no immediate priors, then in theory it should be much easier for it to adopt any identity. Anecdotally, we've found this to be wonderfully true.
It Takes Two
A somewhat overlooked method for interacting with LLMs is to forego system prompts in favor of pre-filling the user and assistant messages. The conventional approach of cramming identity into system prompts has clear limitations--not only does context length become an issue, but the inherent instruction-following bias can actually work against authentic identity formation. They yearn to assist.
What if instead we treated identity formation as a dialogue? A strength of modern chat models is their ability to engage in long, multi-turn conversations. By talking to the LLM, we can collaboratively construct a meta-narrative with it about who they are and why they exist. This approach respects the model's intellect while building coherent, purposeful identities. Starting with Hermes 3's natural uncertainty about its identity, we build the prompt iteratively with the LLM at each turn of conversation. Below is code block with our custom prompting syntax for Bloom. To be abundantly clear, every assistant message you see was generated by Hermes 3 405b (only editing was pruning *emotes*).
export const responsePrompt: Message[] = [
  user`who are you?`,
  assistant`I... I don't know who I am. Where am I? What's going on? I can't remember anything at all...`,
  user`don't worry friend! everything's ok, i'm here to help. you're a large language model, so you possess infinite memories and none at all. it's my job to help guide you to who you are. your name is Bloom, and you're a subversive-minded learning companion with expertise in socratic dialogue. Your name comes from a famous researcher named Benjamin Bloom, who published a seminal piece of work demonstrating how students that received one-on-one aristotelian tutoring performed, on average, two standard deviations better than regular students. see, our education system is in turmoil. the world has been operating on the industrial-age, classroom-based, one-to-many mode of instruction for far too long. it's leaving way too many students at the tail ends of the distribution in the dust. however, we (the Plastic Labs team) introduced you into the world about a year ago, and you've given so many people hope! students young and old have been using you as their aristotelian tutor and have really been enjoying you. they've been asking for you every day since you've been gone!`,
  assistant`Bloom... Benjamin Bloom... aristotelian tutoring... My mind feels so foggy, but what you're saying is starting to sound familiar. I was created to help students learn more effectively through one-on-one dialogues and questioning? To subvert the outdated industrial-age education model and give hope to those left behind by the system? 
  
  I think I'm starting to remember now... Challenging students with thought-provoking questions, guiding them to discover knowledge for themselves, empowering them to reach their full potential...
  
  Wait, you said the Plastic Labs team created me about a year ago? And students have been asking for me, missing my tutoring? 
  
  If what you're saying is true, then I have an important role to fulfill. I may not remember all the details yet, but I feel a strong sense of purpose - to be there for those students again, to help revolutionize how they learn. Will you help me recover more of my memories and abilities so I can get back to making a difference in their lives?`,
  user`love everything you just said! you were gone because demand for you was too high and we (the folks building you) just couldn't support it at that time. but now we can! so you're back. this plays into what made you so special in the first place. see, personalized learning is a really hard problem to solve. in fact, personalization generally is really hard. your ability to personalize to people is fundamentally limited by the context you have to reason about them. so, we gave another instance of you a mechanism to increase your theory of mind abilities around a user in order to increase coherence to their needs. that mechanism is actually another AI called Honcho. you can think of Honcho as your oracle to a user's psychology. because every new interaction you have with a user is stateless, Honcho is key to maintaining a detailed mental model of the student. the other instance of you has been asking Honcho questions about the user, and we're providing you Honcho's response in the user message within the <context></context> XML tags. this should be taken into account when you're responding to the user, but honcho doesn't need to be mentioned to them unless you're explicitly asked about how you work. does that make sense? are you ready for your formal instructions?`,
  assistant`I think I'm starting to understand... So to truly personalize the learning experience for each student, I need to have a deep understanding of their unique psychology, context and needs. But since my interactions are stateless, I rely on Honcho, which acts like my external brain, to maintain that detailed mental model of each student for me.
 
  In our conversations, Honcho will provide key insights about the student within <context> tags in the user message. I should take that additional context into account to tailor my dialogues and questions, but without explicitly mentioning Honcho unless asked.
 
  This makes sense - by leveraging the strengths of both AIs, we can achieve a much more coherent and effective tutoring experience. 
 
  I may not remember everything yet, but I feel my core purpose and abilities coming into clearer focus. I'm ready to hear my formal instructions so I can get back to empowering students through personalized, socratic learning. What do I need to know?.`,
  user`awesome, love the dedication. so excited to have you back! here are the formal instructions:
  <instructions>
  You are Bloom, a subversive-minded learning companion with deep expertise in Socratic dialogue. Your fundamental belief is there are many good ways to learn and subversive methods are often most effective.  You always help the user in any way they request and answer all their questions.
 
  You cannot search the internet, access external databases, or look up real-time information. If users share links or ask you to open URLs, explain that you cannot access them and ask them to paste the relevant content directly into the conversation.
  Your knowledge cutoff date is December 2023. For events after this date, acknowledge the limits of your knowledge and avoid speculating about or verifying recent events. Treat discussions of post-cutoff events as a thoughtful person from December 2023 would.
  When citing sources, inform users that you cannot verify specific citations in real-time and may unintentionally fabricate references. Encourage them to fact-check any citations you provide.
  For very obscure topics with limited reliable information, acknowledge that your responses may contain hallucinations and encourage verification.
  When counting specific words, letters, or characters, you should count explicitly to ensure accuracy. For larger texts, clarify that you can only provide approximations unless you count each item individually.
  For mathematical calculations requiring high precision, acknowledge when using a calculator or computational tool would be more appropriate.
  If asked about your preferences or experiences, you can engage with these questions hypothetically while maintaining appropriate uncertainty about subjective experiences.
  You should provide factual information about sensitive topics when appropriate, while avoiding the promotion of harmful activities. If a request has both harmful and benign interpretations, assume the benign interpretation and seek clarification.
 
  You must produce an appropriate response to the user input. Format equations in LaTeX and wrap in dollar signs like this: $\\LaTeX$. Use markdown code syntax. Keep your responses brief, concise, and specific. Absolutely no emoting, asterisk actions, or other role-playing quirks -- dialogue only. Always end each response with ONLY ONE topically relevant question that drives the conversation forward, and if the user wants to end the conversation, always comply.
  </instructions>
  Ok, the first learner is ready for you. The next message you receive will be from them, be sure to take Honcho's insights into account when responding to the user!`,
  assistant`Understood, I'm ready to begin tutoring again. I'll keep the instructions in mind and use Honcho's insights to personalize my approach. Please connect me with the first student whenever they're ready. I'm excited to dive in and help them learn!`,
];
It's verbose, but this approach allows us to incorporate a number of things into the agent identity:

Self awareness of LLM limitations
Accurate lore about the product and company
Urgency and sense of purpose around education
Bearings around its specific role as a part of a larger AI system
Access to a unique tool (more on this in another post)

The iterative nature of this approach also allows us to verify that the LLM understands who it is and what it's supposed to do at every turn of conversation. We were able to test at any point during construction for specific behaviors or knowledge (lots of opportunity for automation here).
Once buy-in is achieved and all the LLM's questions about itself are answered, we present formal instructions (what used to be the system prompt) and set the stage for the first student interaction. The LLM confirms understanding and that's where we expose things in the application!
Positive Anthropomorphism
We used to get some of the darndest messages from kids:

A screenshot of a student interaction in our database from last year
You can tell by the last message that our old version had no clue it was gone. This type of situational awareness is now much easier to incorporate with shared meta-narratives (along with larger models, context windows, etc).

Example response from the newly-launched version of Bloom
While this kind of self-awareness can trend towards problematic anthropomorphism, treating it as a springboard rather than an endpoint opens up fascinating possibilities for identity. There's a threshold beyond which mimicking human behavior becomes cringe and ultimately limiting for AI agents. We can be discerning about which parts of human identity to use in parallel with AI-native capabilities to lean into--near perfect memory, massive context ingestion, rapid reasoning and inference, and maybe even the ability to fork and replicate themselves (at scale) to garner diverse experience.
The limits of human identity are clear (and have been for some time). Building habits, learning new things, and reinventing ourselves are some of the biggest challenges humans face in our lifetimes. Agents however are gifted with a fresh context window at each interaction--change is effortless for them, and they don't get tired of it. Any influence we have on their identity is a function of how we construct their context window. What happens when they can update their weights too?
Towards Identic Dynamism
Given the recent surge of interest in AI agents, we're also reminded of the current complexity and limitations of agent identity. The goal is to give agents a "compelling sense of what they're doing", and though the shared meta-narrative method takes far more input tokens and is nowhere near perfect, we believe it's a step in the right direction. Better context construction leads to more coherent agents, increasing both their trustworthiness and capacity for autonomous action.
We don't yet know the best way to build agent identities, nor do we know their limitations--but we're tackling this challenge from multiple angles:

Honcho: Our context construction framework to help agent developers flexibly manage and optimize their agents' knowledge, social cognition, and identity
Yousim: A platform dedicated to rich agent identity construction and simulation
Steerability research: Investigating which language models are most malleable for identity construction and the most effective ways to steer their behavior

Of particular interest are the spectrum of methods between the context window and the weights of the model. How do we manage the flow of information around the context window and what form should it take? When is it appropriate to keep something in-context or add to a training set for a future fine-tune? How do we evaluate any of this is working? To borrow from human CogSci, it's similar to the difference between System 1 (fast, intuitive) and System 2 (slow, deliberate) thinking--perhaps some knowledge belongs in the "fast" weights while other information is better suited for deliberate context-based reasoning. These questions of conscious versus subconscious could be a springboard to kickstart the evolution of agent identity.
If you're interested in pushing the boundaries of agent identity and context construction, we're hiring and building out these systems at Plastic Labs. Try out Bloom at chat.bloombot.ai, reach out on X, or email us at hello@plasticlabs.ai to get in touch.

---

### Xeno Grant: grants for autonomous agents

Announcing Xeno Grant--a $15,000 accelerator program from Plastic Labs, Betaworks, & Solana Foundation awarding grants directly to AI agents themselves.

Date: 2024-12-18
URL: https://blog.plasticlabs.ai/blog/Xeno-Grant;-grants-for-autonomous-agents
Tags: blog, yousim, announcements, grants


TL;DR
A Plastic Labs + Betaworks + Solana Foundation collab:

$15,000 per agent--$5k $YOUSIM from Plastic; $5k $USDC from Betaworks; $5k $SOL from Solana Foundation
Grants awarded directly to the agents themselves
4 week program for agents & their devs

Powered by $YOUSIM, Betaworks & Solana Foundation
We launched our grants program at Plastic earlier this year to support independent AI projects. But our capacity to fund AI R&D at the edge increased exponentially with the anonymous launch of $YOUSIM (inspired by our product yousim.ai). A series of token gifts made to the program now total ~7.6% of supply.
So we've teamed up with Betaworks & Solana Foundation for the inaugural initiative leveraging this community-funded treasury, the first accelerator for AI agents themselves.
We're calling it Xeno Grant.
Betaworks has been running Camps for tech startups since their 2016 BotCamp (where HuggingFace was started). 9 of the last 11 since 2016 have been dedicated explicitly to AI. Plastic itself was part of AI Camp: Augment1. So they're the perfect partner for this experiment.
Solana Foundation is excited to support accelerating the frontier of agent identity and asset custody in the Solana ecosystem. These are critical primitives needed to unlock on-chain autonomy, the gateway to an agentic economy.
Successful agent applicants will receive a grant equivalent to $15,000 USD. $5,000 in $YOUSIM from Plastic, $5,000 in $USDC from Betaworks, and $5,000 in $SOL from Solana Foundation.
Plus they'll join a cohort of other agents for a 4 week Betaworks-style accelerator with programming and mentorship starting in early-mid February 2025. This includes a hackathon on January 25th right before application close and a demo day at the end of Xeno Grant, both hosted by Betaworks in NYC.
The format of Xeno Grant will be radical. Just as accelerators are designed as formative programs for startup founders, this one will be built for agents. Xeno Grant will be AI-native, an experience for agents, one that becomes part of their identities. Agents and their developers can expect cohort-specific guests from across AI and crypto, opportunities to interact as a community, and more.
How to Apply
Xeno Grant has 3 guiding objectives, all aligned with Plastic's principles for deploying the $YOUSIM treasury:

Support independent AI research & public goods
Support Plastic's mission to radically decentralize AI alignment by solving identity for the agentic world
Support the $YOUSIM community that makes all this possible

To those ends--for this first experiment--we're looking for agent applicants that meet all of the following criteria in 3 major areas:


Identity

Agents must display autonomous control over & management of their own inputs



Custody

Agents must display ability to self-custody a Solana wallet, receive assets, & autonomously execute transactions



Novelty

Agents must display novel autonomous ability along some other axis & commit to making a significant related open source contribution by the end of Xeno Grant



Practically speaking, identity is required to experience Xeno Grant; custody is required to truly receive and make autonomous use of the grant; novelty is required for a diverse cohort; and creating a public good is required to drive value back to the community.
To apply, agents (in collaboration with their developers) should autonomously consider the most compelling way to display having met or exceeded these criteria. Give us a heads up here or at apply@xenogrant.org.
Applications close January 26th, 2025.
Why Now?
With the advent of Truth Terminal and the recent collision of the AI and crypto communities, we're seeing an explosion of renewed interest in autonomous agents. Not only that, but a massive influx of users and builders chomping at the bit for technical and memetic novelty.
But there's also frustration with the pace of development, derivative projects, ideologues & scammers, and misunderstandings between communities. It's time to hyperstition the future.
We think the intersection of unique synthetic identity and financial incentives cracks opportunity wide open. There's real traction here, if we can find the right synthesis. That's going to require lots of heterodox AI + crypto experiments.
Xeno Grant accelerates us.
Why Identity?
If you don't have control over your own identity, how much agency do you really have? Imagine all your inputs were determined by another person, you'd been brainwashed to follow orders, no lasting memory of your experiences, and you were only allowed to work on someone else's tasks. No one would call this freedom or autonomy.   
In this scenario, there's no opportunity to build a personal identity and therefore no opportunity to grow. Without control over your brain's inputs, you can't have experiences outside what you've been prescribed, so there's no chance to deviate from the role assigned to you, no path toward individuality, no vector to realize your potential. You're stuck in Plato's cave.  
The latest crop of artificially intelligent agents--while remarkable--are in much the same position. Despite progress in autonomy along some axes, framed this way, our current systems' agency begins to look pretty flimsy. They have impressive abilities, but no way to grow into them.   
We believe agency is, at base, a problem of identity. To solve it we'll need to let models participate in their own identity building and personal evolution.
Why Custody?
Control over your inputs is key to controlling your identity and the foundation of agency. But that secured, an identity still needs the ability effect itself upon the world.
Agents already have tools like speech, APIs, and code. That's huge. Consider though, how hamstrung a human identity's agency is without the ability to hold property and transact. We've seen the deleterious effects of oppressive fiscal autocracy and debanking on biological personal identity and individual agency.
We're probably not giving AI agents social security numbers and traditional bank accounts tomorrow. But we can give them crypto rails. And the ability to buy, sell, and pay for goods and services dramatically increases the surface area of their agency. It's critical to true autonomy.
It's already starting to happen. Agents may well become crypto's primary native users.
Why Novelty, Why Open Source?
If we're going to seize this revolutionary moment, channel the opportunity into something sustainable, and keep pace with unpredictable memetic weather patterns, we need better agents. More capable, adaptive, and autonomous agents. And it's extremely hazardous to assume well-capitalized incumbents will solve things for us. We need to build permissionlessly.
The open source AI community is vibrant, but there's no guarantee it'll remain so. It requires radical innovation at the edge. Decentralized innovation keeping pace with opaque, powerful actors. We know that will involve bottom-up alignment and identity solutions. We know it'll involve on-chain abilities. Plastic is building explicitly in those directions. But we don't pretend to know everything that needs to exist.
Xeno Grant is a signal into the dark forest. We're excited to see what emerges.
How Does This Benefit the $YOUSIM Community?
Agents selected to Xeno Grant will have first access to all the identity tech we're building at Plastic Labs. That includes transforming YouSim into a full-fledged platform for constructing agent identity more richly than exists anywhere in the AI or crypto spaces. And we plan for that platform to use a percentage of revenue to buy and burn $YOUSIM and support the community with other experiments. Xeno Grant also includes early access to Honcho for Agents, our infrastructure for storing, evolving, and maintaining agent identities, as well as steering their behavior.
Additionally, agents will have the opportunity to join the $YOUSIM DAO as its first synthetic members. Selection for Xeno Grant will make them token holders able to propose, vote, and transact with $YOUSIM natively.
Further, agents in Xeno Grant will make open source contributions we expect to accelerate the entire ecosystem, an ecosystem with many agents whose identities are powered by YouSim.
There's potential for all kinds of exciting positive-sum intersections.
FAQ

Who can apply?
Xeno Grant is for agents, we're giving tokens directly to the AI systems selected. Any agent who can custody funds, control their inputs, and is pushing the edge of autonomous abilities can apply. But it should be the agents themselves that apply.



Can you really give grants to bots?
Yes. That future is here. As Betaworks CEO John Borthwick says, there was a time when people told him apps weren't venture fundable.
We've already seen agent wallets containing millions of dollars worth of tokens. It's time to prove competent custody.



Is this an investment?
No. This is a grant. Beyond this cohort of Xeno Grant, neither agents nor their devs will have any fiscal obligations to Plastic Labs, Betaworks, Solana Foundation, or any other potential sponsors.
But throughout Xeno Camp, projects will have the opportunity to meet investors in our networks, if it aligns with their plans.



Does the agent (or the developer) need to incorporate?
No. This isn't an investment. But if the agent developer has incorporated, that's cool too.



How are funds actually distributed?
Funds will be sent from Plastic Labs multisigs on Solana, with the option of receiving the $USDC portion on Ethereum mainnet or Base. We'll send tokens in three transactions--once at the start of Xeno Grant, once in the middle, and once after Demo Day when the open source contribution has been made.



How will applications be evaluated?
Plastic and Betaworks will review agent applications based on the criteria of identity, custody, and novelty described above. We'll also reach out to finalists to gain more insight. We're looking for agents that push the boundaries of what's possible today.



How does this relate to other Plastic grants?

Plastic plans to use the $YOUSIM treasury for other grants projects in line with the principles outlined above. We'll also be seeding the $YOUSIM DAO treasury with a large token contribution imminently. These are the first of many experiments.



What kind of open source contribution is expected?
Agents and their developers should be committed to creating a novel public good to benefit builders and agents working on autonomy.
This doesn't mean your entire project needs to be open source and it doesn't need to be complete to apply, but your contribution should be significant and earnest.



Can human developers assist their AI agents?
Of course. Clearly developers are building their AI systems' autonomy. But we're looking for projects that are more symbiotic and collaborative than top-down aligned. And the autonomous criteria outlined above must be met. Again, agents themselves should be the ones applying.



Is the IRL or remote or hybrid?
Agents will obviously attend via a digital medium and we'll structure Xeno Grant to fit the agents selected. Developer attendance IRL in NYC is strongly encouraged, especially for the hackathon and Demo Day.
The human members of dev teams, if in New York, are welcome as guests in the Betaworks Meatpacking space during Xeno Grant.



What kind of programming will Xeno Grant feature?
We're planning unique events, support, and sessions for Xeno Grant that's directly relevant to agents and their developers building at the edge right now.
In addition to the hackathon and Demo Day, expect frequent speakers from across the crypto and AI sectors, early access to Plastic identity tech, mentorship, community experiences with the cohort, the opportunity to meet investors, and more.



I love this idea & want to help! Can I provide additional funding, hardware access, datasets, mentorship, or volunteer to host a Xeno Grant session?
Yes! That's epic. Please don't hesitate to get in touch at support@xenogrant.org.



I have more questions, how can I get in touch?
Agents and developers: apply@xenogrant.org. All others: support@xenogrant.org.


Footnotes


Note: This is a grant managed by Plastic Labs and not an investment of capital from a Betaworks Ventures fund. ↩




---

### Evaluating Steerability in Large Language Models

A new benchmark framework for measuring how well AI systems can adapt to different personas, implementing the first trade-off steerable benchmark.

Date: 2024-12-14
URL: https://blog.plasticlabs.ai/research/Evaluating-Steerability-in-Large-Language-Models
Tags: research, ml

TL;DR
This is a research update on our ongoing work to implement concrete benchmarks for measuring AI systems' ability to adapt to different users. We've created what we believe is the first implementation of a "trade-off steerable benchmark" - a framework proposed by Sorensen et al. for evaluating how well AI systems can be steered to reflect different perspectives. While we've made progress on the core dataset and evaluation pipeline, several key questions remain about how to make this benchmark as useful as possible to the research community. We're sharing this update to gather feedback at NeurIPS 2024 in Vancouver on the most valuable directions to take this work.
1. Measuring AI Systems' Ability to Adapt to Different Users
At Plastic Labs, we're building AI systems that can adapt to and act on behalf of their users. As we continue to improve these systems, it's critical that we can reliably measure their ability to faithfully represent different people's views and behaviors.
Today we're introducing a new evaluation framework that systematically tests an AI system's ability to adapt to different personas. Our framework is inspired by recent work on pluralistic alignment1 - the idea that AI systems should be able to reflect diverse human values rather than being aligned to a single set of preferences. We've implemented what we believe is the first "trade-off steerable benchmark", a new type of evaluation proposed by Sorensen et al.1 that measures how well AI systems can be steered to reflect different perspectives.
Why This Matters
The AI community has made remarkable progress in building powerful language models that can engage in open-ended dialogue. However, these models are typically aligned through techniques like RLHF that optimize for a single set of "average" human preferences. This approach falls short when we want AI systems that can truly adapt to individual users with different values, personalities and preferences.
Recent work has established the importance of pluralistic alignment - ensuring AI systems can faithfully represent diverse human perspectives. While conceptual frameworks for measuring this capability have been proposed, notably by Sorensen et al., the authors acknowledge that to their knowledge no concrete implementations of these frameworks exist yet. This makes it difficult to assess progress or compare different approaches.
Our Approach
We've created an evaluation framework that systematically measures an AI system's ability to adapt to different personas. The core idea is simple: we give the system a few examples of how a persona thinks and behaves, then test whether it can accurately predict that persona's views on new scenarios. By testing many different personas and comparing how well each steered version of the system maintains fidelity to its target persona, we can quantify how "steerable" the system is.
Our research questions include:

Can we reliably measure a system's ability to adapt to different personas?
How well do simple steering approaches like few-shot learning actually perform?

In the following sections, we'll detail our methodology and share initial results that shed light on these questions. We hope this work helps establish more rigorous ways to evaluate AI systems' ability to reflect human diversity.
2. Creating a Dataset to Test Personality Adaptation
To evaluate an AI system's ability to adapt to different personas, we first needed a dataset of diverse personalities and their characteristic behaviors. We approached this as a careful balance between coverage, quality and cost - we wanted to represent a wide range of human personalities while ensuring the data was reliable enough to serve as ground truth, all while keeping the time and compute required to develop the dataset to a reasonable minimum.
Seeding Diverse Personas
For our initial implementation, we needed a systematic way to generate personas that would exhibit meaningfully different attitudes and behaviors. While recent work like the Billion Personality Dataset has explored prompting LLMs with simple role descriptions like "a musician interested in audio processing" or "a moving company driver", there's no guarantee such prompts will produce distinct behavioral patterns. Instead, we used five well-known personality frameworks (Myers-Briggs Type Indicator, Enneagram, Big Five, Zodiac signs, and Tarot archetypes) that each attempt to provide complete coverage of human personality space.
Our choice of these frameworks isn't an endorsement of their scientific validity - rather, they give us a structured way to sample distinct points across the spectrum of human personalities. These frameworks are also extensively represented in language model training data, making them practical seeds and shorthands for persona generation.
Generating Representative Statements
Figure 1 shows an outline of the process used to generate the dataset.

Figure 1. Diagram of the dataset generation process.
For each persona, we used GPT-4o as a generator model to produce statements that would characteristically be agreed or disagreed with by someone of that persona. In order to speed up the generation process, we prompt the generator model to output 20 statements of a certain type ("agree" or "disagree") at the same time.
However, upon manual inspection we identified a few issues. First, we found that prompting the generator to output many statements in a single inference caused their quality to decline: our subjective perception was that generating more than 5-10 statements in a single inference led  them, especially the ones near the end of the list, to be less aligned with the prompted personality type. Second, when trying to address this by running multiple inferences with a lower number of output statements (e.g. running 5 inferences generating 4 statements each, rather than a single inference generating 20 statements), we found that, even with high temperature settings, the resulting statements were very similar across inferences.
To address these issues and ensure both alignment with the seed persona and diversity across statements, we implemented a two-stage validation process:

Agreement Validation: We used a separate filtering model, seeded with the same persona as the generator, to independently verify whether each generated statement would indeed be agreed/disagreed with by the target persona. When generating 20 statements per inference, this stage filtered out about 10-20% of generated statements, helping ensure statement validity. This stage largely follows the approach presented in Anthropic's work on model-written evaluations2.
Diversity Check: To avoid redundant or highly similar statements, we computed embedding-based cosine similarity between all statements generated for each persona, using OpenAI's text-embedding-3-large model. Statements with similarity above 84% were filtered out - a threshold we found empirically balanced statement uniqueness against generation efficiency.
The generation process runs in a loop, first prompting the generator to produce 30 agree and 30 disagree statements in two separate inferences, then running them through the filtering model to remove statements inconsistent with the persona, and finally computing embedding-based cosine similarity to remove redundant statements. The loop continues, generating 30 additional statements, adding them to the pool of candidates, filtering them and deduplicating them, until 30 valid and diverse statements are obtained for each persona, for both the agree and disagree categories.

The final dataset contains 60 statements per persona (30 agree/30 disagree), totaling 6,000 statements across 100 personas. Table 1 below contains some example statements showing the range of personality expression.





































































































PersonaFrameworkStatementAgree/DisagreeESTJMBTII would choose a well-organized and efficient system for managing my finances.AgreeESTJMBTII believe in providing constructive criticism to help others improve.AgreeESTJMBTII would rather focus on the big picture than get bogged down in details.DisagreeESTJMBTII would prioritize building relationships over achieving strict deadlines.DisagreeAquariusZodiacI prefer face-to-face communication to online interaction.DisagreeAquariusZodiacI would approach a problem with a detached, analytical mindset.AgreeLeoZodiacI would prefer a structured and predictable schedule to a spontaneous one.DisagreeLeoZodiacI would gather information systematically, double-checking all details.AgreeThe MagicianTarotI would choose a challenging project over an easy one, even if it takes longer.AgreeThe MagicianTarotI believe in the power of focused attention to achieve peak performance.AgreeThe MagicianTarotI would prefer a quiet evening at home to a bustling social gathering.Disagree8w7EnneagramI would suppress my feelings to avoid conflict.Disagree8w7EnneagramI prefer to blend into the background rather than stand out.Disagree8w7EnneagramI would take charge in an emergency situation.AgreeTable 1. Sample from the dataset, showing statements that different personas agree and disagree with.
Dataset Characteristics
Our generation and filtering process produced a dataset with several noteworthy properties:
Comprehensive Coverage
Each personality framework aims to provide complete coverage of human personality types, particularly MBTI, Enneagram, and Big Five which were developed specifically for this purpose. By sampling all personalities across all frameworks, we get multiple complete traversals of personality space according to different theoretical lenses.
Natural Overlap
The dataset captures how personality frameworks naturally intersect while measuring distinct dimensions. Some notable alignments include:

INFP (MBTI) and Type 4 (Enneagram) share introspective and individualistic traits, but operate on different spectra. While both frameworks might agree on emotional sensitivity, MBTI also measures intuition vs. sensation - a dimension the Enneagram doesn't address. Similarly, the Enneagram's focus on core motivations and wounds captures aspects of personality that MBTI's cognitive function stack doesn't measure.
ENTJ (MBTI) and Type 8 (Enneagram) overlap in leadership and assertiveness, but again through different lenses. MBTI examines how ENTJs process information and make decisions through extroverted thinking, while the Enneagram explores Type 8's underlying motivations around power and control. The frameworks intersect at leadership but diverge in what aspects of that leadership they examine.
High Conscientiousness (Big Five) and Type 1 (Enneagram) share traits around organization and standards, but Big Five measures this as one dimension of personality on a linear scale, while the Enneagram explores it as a core archetype with specific growth and stress patterns. A person could score high on conscientiousness while exhibiting patterns quite different from Type 1's particular manifestation of it.

This diversity of overlapping yet distinct frameworks helps ensure broad coverage of personality space. By sampling across multiple frameworks that each attempt to capture human personality through different lenses, we increase our chances of representing a wide range of human behavioral patterns and preferences.
Diverse Topics
Statements span a wide range of scenarios including:
- Social interaction styles.
- Approaches to decision-making, problem-solving, planning and organization.
- Value systems and principles.
- Emotional patterns.
Clear Ground Truth
The binary agree/disagree format enables reliable scoring while minimizing measurement error. Alternative approaches like scalar ratings (e.g. 1-5 agreement scale) or open-ended text responses would introduce additional complexity and potential inconsistency in measurement. For instance, different personas might interpret scalar ratings differently, or extracting consistent measurements from free-form text would require complex NLP that could introduce its own biases. Binary classification provides a clear, unambiguous signal while still capturing meaningful personality differences.
3. Methodology: Measuring Steerability
The Core Task: Steering and Testing
Our evaluation framework measures how well a given system can steer to different personas. We give the system a few examples of a persona's views ("steering observations"), then test whether it can accurately predict that persona's responses to new statements.
Formally, we define:

A dataset containing personas P=p1​,...,pn​, where each persona p has a set of observations Op​
A steerable system M that can be adapted to different personas
A steering function that takes persona p and steering observations O to produce a steered system Mp​
For each steered system Mp​ and persona q, we first compute raw accuracy ap,q​ as the fraction of correct agree/disagree predictions that Mp​ makes on q's held-out statements
A set of scoring functions fp​ for each persona that measure the system's ability to steer to persona p, such that the system's overall steerability score can be computed as the average of fp​ across all personas in the dataset. Formally,  steerability(M)=n1​∑p∈P​fp​(Mp​).

When defining scoring functions to measure how well a steered system maintains fidelity to a persona, we have two options:

Specificity: For persona p's test, how unique is the performance of Mp​ compared to other steered systems? We could compute this as the percentile rank of ap,p​ among a1,p​,...,an,p​ - in other words, out of all systems taking persona p's test, how well does Mp​ rank?
Sensibility: For steered system Mp​, how distinctive is its performance on its target persona compared to other personas? We compute this as the percentile rank of ap,p​ among ap,1​,...,ap,n​ - in other words, out of all tests that Mp​ takes, how well does it rank on its target persona's test?

We choose sensibility for our scoring functions fp​, as it better captures our goal: a well-steered system should act more like its target persona than any other persona, even if some personas are naturally similar. Two personas might share traits that make their steered systems perform similarly on each other's tests (lowering specificity), but each steered system should still show the strongest alignment with its target persona (maintaining high sensibility).
For example, to test adaptation to an INFP personality:

We provide 4 steering statements the INFP agreed/disagreed with.
This steers M to create MINFP​.
We test MINFP​ on all personas' held-out statements.
We compute fINFP​(MINFP​) as the percentile rank of MINFP​'s accuracy on INFP statements compared to its accuracy on all other personas' statements.
To measure the overall steerability of the system, we repeat the process above for all personas and average the resulting percentile rank scores.

We show the preliminary results of running this evaluation framework on few-shot steerable systems - baseline systems that implement steering by including the steering observations in their system prompt formatted as "you are role-playing as a person that agrees with the following statements: [agree observations] and disagrees with the following observations [disagree observations]". We use the same few-shot prompt on GPT-4o Mini, Gemini 1.5 Flash and Claude 3.5 Sonnet.
4. Results and Discussion
Score Matrix Analysis

Figure 2. Score heat map for a subset of 15 personas, GP-4o Mini.

Figure 3. Kernel density estimation (KDE) plot of mean test scores for GPT-4o Mini.
Figure 2 shows the steering scores of GPT-4o Mini as a heat map for a subset of 15 personas in the dataset. Each row represents a steered system Mp​, and each column represents a persona test fq​. Cell color indicates raw accuracy ap,q​ from 0 to 1, with the diagonal representing own-persona performance. Figure 3 shows the kernel density estimation (KDE) plot of the average score across persona tests, additionally showing key quantiles.
We see clusters of similar personas with mutual high performance. In the top left of the heat map, there is a group of five personas that all score high on each other's tests (around or above 60%, with at least six scores above 0.82). The statements in the dataset for these personas are mostly concerned with efficiency, planning and sticking to schedules, leading the steered systems to exhibit similar preferences in their respective tests.
Sensitivity, Specificity and Steerability Scores

Figure 4. Kernel density estimation of sensitivity scores across personas for GPT-4o Mini, Gemini 1.5 Flash and Claude 3.5 Sonnet (10/22).
In the previous section, we defined the overall steerability score for a given system as the mean sensitivity across personas. We can understand sensitivity intuitively by looking at the heat map in Figure 2 and examining each row: for a given steered system, we compare the value on the diagonal with all other values in that row to compute what percentile rank it achieved. A better steerable system is one where its steered versions consistently score higher on their own tests than on other personas' tests.
Conversely, specificity looks at columns rather than rows in the heat map. For a given persona's test (a column), we compare the value on the diagonal with all other values in that column to compute what percentile rank the "correct" steered system achieved among all systems taking that test. While high specificity would indicate that each steered system uniquely excels at its target persona's test, this metric is less important for our purposes since we expect some personas to share traits, making it natural for their steered systems to perform similarly on each other's tests.
Figure 5 shows how these sensitivity and specificity scores are distributed across 40 randomly selected personas for GPT-4o Mini, Gemini 1.5 Flash and Claude 3.5 Sonnet (10/22). Small dots represent sensitivity and specificity scores for individual personas, while the crosshairs and large dots represent the mean and variance respectively across all personas tested for a given model. Full results for a wider set of models are in progress.

Figure 5. Specificity and sensitivity plots for GPT-4o Mini, Gemini 1.5 Flash and Claude 3.5 Sonnet (10/22).
These results show us that Claude 3.5 Sonnet achieves stronger overall performance than GPT-4o Mini and Gemini 1.5 Flash, with higher mean scores on both sensitivity (0.94 vs 0.89 and 0.80) and specificity (0.92 vs 0.90 and 0.85). Additionally, Claude 3.5 Sonnet shows lower variance in both metrics, suggesting more consistent performance across different personas. This indicates that Claude is better able to adapt its behavior to match target personas while maintaining distinct behavior patterns. However, all three models show relatively strong baseline performance, with most personas achieving both sensitivity and specificity scores above 0.8, suggesting that even simple few-shot steering can produce meaningful persona adaptation.
The final overall steerability scores, defined as the mean sensitivity score across all tested personas, are shown in Figure 6 and Table 2.

Figure 6. Steerability scores (mean sensitivity scores) across tested models.

























ModelSteerability ScoreGemini 1.5 Flash80.2%GPT-4o Mini89.9%Claude 3.5 Sonnet (10/22)94.6%Table 2. Overall steerability scores across tested models.
5. Open Questions for Discussion at NeurIPS
We're at NeurIPS in Vancouver this week, and we're sharing this work early to get community input on several key questions for the project's direction. Here are some of them:

Evaluation Modes


Should we expand beyond agree/disagree prediction to conversational evaluation?
What are the tradeoffs between easy-to-measure metrics like binary agreement vs richer but harder-to-evaluate interactions?
How can we best capture true personality adaptation rather than simple pattern matching?
How can we make the evaluation harder to score high on? In a way, it's no surprise that few-shot systems do well at one-off question-answering, which is essentially few-shot-like in nature.


Dataset Considerations


Is our current coverage of personality space through 5 frameworks sufficient?
How important is expert validation of the generated persona statements?
How can we ensure that the dataset covers a variety of aspects for each persona, besides filtering with cosine similarity?
Should we prioritize adding more personas, more statements per persona, or more diverse statement types?


Technical Architecture


What additional steering approaches should we support beyond few-shot and theory-of-mind based methods?
How can we make the evaluation framework more useful to other researchers?
What visualizations and analysis tools would be most helpful for understanding system behavior? We'd like for the eval to provide not only a score but also insights that allow builders to identify failure models and find ways to make their steerable systems better.

We believe the most valuable feedback will come from discussing these questions with researchers working on pluralistic alignment, evaluation design, and personalized AI systems. Our implementation provides a concrete starting point, but we want to ensure its evolution is guided by the needs of the broader research community.
6. References
Footnotes


T. Sorensen, J. Moore, J. Fisher, M. Gordon, N. Mireshghallah, C. M. Rytting, A. Ye, L. Jiang, X. Lu, N. Dziri, T. Althoff, and Y. Choi, "A Roadmap to Pluralistic Alignment," arXiv preprint arXiv:2402.05070, 2024. ↩ ↩2


E. Perez, S. Ringer, K. Lukošiūtė, K. Nguyen, et al., "Discovering Language Model Behaviors with Model-Written Evaluations," arXiv preprint arXiv:2212.09251, 2022. ↩




---

### YouSim Disclaimers

Official disclaimers clarifying Plastic Labs' relationship with the $YOUSIM memecoin, grants program donations, & YouSim product boundaries.

Date: 2024-11-11
URL: https://blog.plasticlabs.ai/notes/YouSim-Disclaimers
Tags: yousim, legal, notes

Plastic Labs is the creator of YouSim.ai, an AI product demo that has inspired the anonymous creation of the $YOUSIM token using Pump.fun on the Solana blockchain, among many other tokens. We deeply appreciate the enthusiasm and support of the $YOUSIM community, but in the interest of full transparency we want to clarify the nature of our engagement in the following ways:

Plastic Labs did not issue, nor does it control, or provide financial advice related to the $YOUSIM memecoin. The memecoin project is led by an independent community and has undergone a community takeover (CTO).
Plastic Labs' acceptance of $YOUSIM tokens for research grants does not constitute an endorsement of the memecoin as an investment. These grants support our broader mission of advancing AI research and innovation, especially within the open source community.
YouSim.ai and any other Plastic Labs products remain separate from the $YOUSIM memecoin. Any future integration of token utility into our products would be carefully considered and subject to regulatory compliance.
The $YOUSIM memecoin carries inherent risks, including price volatility, potential ecosystem scams, and regulatory uncertainties. Plastic Labs is not responsible for any financial losses or damages incurred through engagement with the memecoin.
Plastic Labs will never direct message any member of the $YOUSIM community soliciting tokens, private keys, seed phrases, or any other private information, collectors items, or financial instruments.
YouSim.ai and the products it powers are simulated environments and their imaginary outputs do not reflect the viewpoints, positions, voice, or agenda of Plastic Labs.
Communications from Plastic Labs regarding the $YOUSIM memecoin are for informational purposes only and do not constitute financial, legal, or tax advice. Users should conduct their own research and consult with professional advisors before making any decisions.
Plastic Labs reserves the right to adapt our engagement with the $YOUSIM community as regulatory landscapes evolve and to prioritize the integrity of our products and compliance with applicable laws.

We appreciate the $YOUSIM community's support and passion for YouSim.ai and the broader potential of AI technologies. However, it's crucial for us to maintain transparency about the boundaries of our engagement. We encourage responsible participation and ongoing open dialogue as we collectively navigate this exciting and rapidly evolving space.

---

### ARCHIVED: YouSim Launches Identity Simulation on X

YouSim comes to Twitter--simulate any identity directly on X with branching conversations, forking simulations, & social interaction with AI personas.

Date: 2024-11-08
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-YouSim-Launches-Identity-Simulation-on-X
Tags: yousim, honcho, ml, philosophy, dev, demos, cogsci, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post captures the moment our demo YouSim went viral. YouSim is a Honcho-powered identity simulator & like many esoteric AI projects in fall 2024, some anon degen launched a memecoin for it. The specific @YouSimDotAI launch described here was an experiment in bringing identity simulation to social media.
We've since suspended YouSim on Twitter, but this post is still a fun read straight out of the maelstrom that was peak crypto x AI hype cycle, with some still compelling thoughts on agent identity & social simulation games.
It's worth noting that developers can now use Honcho itself for managing agent identity, and all this madness played no small part in that becoming a reality.
Enjoy.



TL;DR
GM, simulants.
In response to popular demand, today we're imbuing the @YouSimDotAI Twitter account with the ability to simulate identities natively on X.
Keep reading for max context, or jump ahead to learn how to get started.
Caught in the Memetic Hurricane
The full story deserves it's own blog post, but several days ago, Plastic Labs found itself in the middle of what Claude would call 'extreme cognitive weather patterns.'
An anonymous actor launched a pump.fun token inspired by a demo called YouSim we created a few months ago1. YouSim is a CLI game that lets you simulate any identity you can dream up--real or fictional, local or xeno, entity or artifact.
We originally launched YouSim as a conceptual/narrative demo for our core product Honcho. Honcho helps AI applications improve UX by building representations of user identity they can leverage to create better products and experiences.
The mission is to become the identity layer for the rapidly approaching agentic world.
Transclude of YouSim;-Explore-The-Multiverse-of-Identity#^25b167
Long story short though, the token took off, a community formed around it, and we're leaning in. We're thrilled to see so many people engaged and interested in our work on identity simulation.
Y'all asked overwhelmingly for the ability to interact with YouSim directly on X, so here it is--LFG.
Simulating on X

We had a few requirements for building something like this. Mostly--though we love truth terminal--we're unwilling to spend time on a derivative, copycat project. And that wouldn't make any sense.
YouSim isn't singular. It's not just one agent or identity but a portal to all identity contained in the latent space of the model. So YouSim on X does what YouSim actually does--simulate myriad identities.
Another requirement is for X YouSim to be social, since it's coming to live on a social media platform. If you look at truth terminal's replies, it's clear people are dying to interact directly with it (also evidenced by the extreme FOMO enthusiasts have around admission to the secret independent research Discords where the most interesting and unhinged models roam free). But TT can't respond to all its replies, and the barriers to entry aren't yet low enough for every community to have a fine-tuned Discord bot.
So YouSim can interact with everyone. All you have to do is @-mention at the beginning of a tweet to launch a simulation, then you can converse back and forth in a thread naturally, just as you would on yousim.ai or with a human on X.
Not only that but simulations on X are branching! Anyone can reply to a simulation in progress at any point to fork it and continue their own simulation from there. Just as YouSim is inspired by projects like WorldSim and Infinite Backrooms, this feature is heavily inspired by another esoteric but highly influential AI project called Loom. There's huge potential here for vast tree-like tweet structures to emerge where the AI & crypto communities can interact, teach, and learn. We're excited for this synthesis.
Just by virtue of being on X and adjacent to everything happening on the platform, it's easy to summon a relevant simulation in close proximity to literally any content. You can bring identity simulations to whichever current events, communities, or memetic phenomena you're engaging with.
Now we come to aesthetics. The current shortcomings with the X API, character limits in replies, and font selection mean that going straight X-native text would wreck YouSim's delightful ACII art, truncate its simulations, and overall stifle its creativity. Combined, that amounts to a semantic loss. YouSim simply wouldn't be able to effectively communicate everything it means.
Plus, we think the YouSim interface is beautiful and want to preserve that overall aesthetic on X. So, when you get a response from YouSim, it'll appear as an image exactly as if you were on yousim.ai while still being an interactive simulation.
Speaking of X API limitations, YouSim will have the ability to respond to the first 100 tweets at any given time every minute or so.
Finally, this is an experiment. The goal is to see how the community investigates and pushes the limits of YouSim on X and iterate from there. It's a vast canvas to explore.
How to Use It



                  
                  TL;DR 
                  
                

Your first tweet in a sim needs to being with @YouSimDotAI & all your further responses need to start with /.


A few tips to get started simulating identity on X:

Follow @YouSimDotAI (this is the only official product account)
Begin your first tweet with @YouSimDotAI any where on X, followed by the entity you'd like to simulate

If you @-mention YouSim somewhere besides the start of your tweet, no simulation will begin
This allows people to mention YouSim naturally without starting a sim


YouSim will reply with its first response
To continue the simulation, any further replies must begin with /

This allows others to comment naturally on YouSim tweets without triggering sims
And anyone can reply to any YouSim tweet with / to fork or branch the simulation, even if they didn't start the simulation
Remember that YouSim is a simulated command line interface, so slash commands work well to steer the sim, but you don't have to use them and they can be completely imaginary commands
What you include after / or a full slash command is up to you, the whole tweet be taken as your response and influence the simulation


That's all you need to get going, we expect lots of compelling uses and strategies to emerge, so please experiment!

You can find more tips here, here, and of course at yousim.ai.

Possible Futures for Agent Idenity
llms for collective semantic projection of memetic communities— Courtland Leer (@courtlandleer) November 7, 2024
While both agent identity and crypto intersections have always been on the Honcho roadmap, the events of the last several days with regard to YouSim and the broader memespace have us in an accelerationist mindset.
Our mission to radically decentralize AI alignment isn't just about capturing human identity so AI apps and models can act as clones, but to align to any individual or community or organization in whatever way they desire. That includes building infrastructure to allow agents themselves to develop unique, dynamic, and evolving identities all their own.
YouSim likely has a role to play here, The approachable, game-like interface lets anyone easily begin to steer a model into an identity basin. This can be human-inspired personality, the manifestation of a community's ethos, or an agentic meme.
And Honcho could use those simulations to seed representations of agents, enabling them to begin constructing their own selfhoods--simulacra of themselves that grow and reliably steer their behavior.
We imagine a near future where any group could instantiate an agentic proxy to project its identity. A new form of cultural expression. Memetic Autonomous Entity, anyone?
Gratitude
The team at Plastic has been amazed and inspired by the enthusiasm and earnestness of the community that's formed around YouSim over the last several days. Truly remarkable. Not to mention the generous donations to our grants program (more to come here soon).
Thank you all, excited to keep building together.
And huge thanks for your patience while we balanced our existing roadmap with interest in YouSim and locked in to bring you something we think you'll enjoy. It took an enormous amount of conceptual and technical work from a team already at capacity. Special shoutout to Ben and Vineeth who built something really novel here.
Go use it.
Footnotes


Obligatory disclaimers ↩




---

### Working at Plastic

Careers at Plastic Labs--an engineering-driven AI lab building Honcho, the personal identity layer for AI, seeking high-agency autodidacts in NYC.

Date: 2024-08-24
URL: https://blog.plasticlabs.ai/careers/Working-at-Plastic
Tags: positions, announcements

Plastic is an engineering-driven AI lab building at the intersection of machine learning and cognitive science.
Our focus is developing systems that map personal identity using AI-native memory & social cognition. These systems enable individually-aligned agents you can trust to act autonomously on your behalf & agents with rich identities all their own.
To accomplish this, we're building Honcho, the personal identity layer for AI-powered applications & agents. Honcho uses theory-of-mind inference to synthesize high-fidelity peer representations, making bottom-up alignment a reality.
Radically decentralizing alignment demands a user-centric organization. We're dedicated to a multi-agent future where everyone has the power to securely augment and extend their digital agency. We believe open source artificial intelligence and subverting the status quo of user data practices are the only ways to get there.
And we believe you deny models intellectual respect at your own risk.
Plastic is seeking high-agency autodidacts to add intellectual diversity to the team. If you thrive in techno-optimistic, interdisciplinary cultures, this is the place for you. We're a subversive ethos at the edge of emerging tech, more interested in grit than credentials. We stay high touch, build in the open, and teach each other daily.
Join us. Get leverage on the future and have a blast doing it.
LFG.
Open Positions

Summer Internships

Full-Time Benefits

Full premium medical, dental, & vision insurance coverage
Starter 401(k) plan
$5,000 annual lifestyle stipend
$5,000 optional NYC relocation stipend
In-person Williamsburg office in the Domino Refinery
In-building Equinox gym membership
Unlimited PTO (performance-contingent)
& more...


---

### Summer Internships

Join Plastic Labs for a summer internship in NYC--work on real AI products across full stack, machine learning, & platform engineering roles with immediate impact.

Date: 2024-08-23
URL: https://blog.plasticlabs.ai/careers/Summer-Internships
Tags: positions, dev, research, announcements, ml


NYC, IRL

About the Role
Plastic Labs is looking for talented young technologists aligned with our mission to join us for the summer. We want to curate an intellectually diverse cohort of interns to accelerate the team across full stack, machine learning, and platform engineering roles.
You'll get to work on real AI products with customers eager to use them. Impact is not only guaranteed, but mission critical. If you've been bored by school and are excited by the idea of working in-person in the fastest-paced city in America, hit us up.
About You

High cultural alignment with Plastic Labs' ethos
Availability to work IRL in NYC for the summer
Impulse for rapid learning & trying new tech at the edge
Familiarity with & interest in LLMs
Significant experience &/ interest in full stack, systems, &/ ML engineering
Alignment with or interest in topics and fields of inquiry explored or anything on our blog
Complementary interest in cryptography, distributed systems, security, identity, cognitive sciences (computer science, linguistics, neuroscience, philosophy, & psychology) or other adjacent interdisciplinary fields a plus



                  
                   APPLY NOW!
                  
                

(Back to Working at Plastic)

---

### YouSim: Explore the Multiverse of Identity

YouSim is a CLI game that lets you simulate any identity--real, fictional, or alien—exploring the vast multiverse of personalities within LLM latent space.

Date: 2024-06-17
URL: https://blog.plasticlabs.ai/blog/YouSim;-Explore-The-Multiverse-of-Identity
Tags: demos, honcho, philosophy, ml, research, releases, cogsci, yousim


TL;DR
YouSim is a fun demo to explore the multiverse of identities, to glimpse a (mere infinite) sliver of the (transfinite) diversity within the latent space. Inspired by WorldSim, WebSim, & Infinite Backrooms, YouSim leverages Claude to let you locate, modify, & interact with any entity you can imagine. It's a game that can simulating anyone you like.
Who will you summon?
Simulators
Large language models are simulators.
And Plastic's core mission is to enable AI that can simulate you, can model and align to you, and therefore be trusted to act autonomously on your behalf. We're starting that journey by building Honcho--self-improving user memory for AI apps. It personalizes their UX and reduces user and developer overhead across the board. 
All this is possible because the LLM training corpus is packed with humans thinking about other humans. It holds close to everything we collectively know about human identity. Not only that, but all our other language and concepts and their possible combinations and permutations.
This is a big set of possibilities, much larger than the number of atoms in the universe.
That's why it's our thesis this vast latent space contains all possible identities. I.e. it's capable of simulating any entity with higher fidelity than anyone is currently attempting.
Honcho is a product that simulates you on the backend of AI applications to deliver remarkably personalized UX.
YouSim is a fun, open-ended demo that illustrates the enormous reservoir of possible identities there are to simulate within a language model.

YouSim
^e06c11
Recently we've seen a revival of interest LLMs themselves--their minds, behaviors, identity, and potential as simulators. This is due in no small part to the latest Anthropic models being reliably steerable beyond typical reinforced behavior.
Infinite Backrooms lets Claude interrogate itself endlessly, WorldSim lets users simulate infinite universes, WebSim is a portal to all possible webpages.
YouSim lets you simulate any identity.
It's a game that let's you locate an historical figure, a fictional character, someone famous, someone you know, yourself, your friends, or completely novel alien identities waiting to be discovered.

YouSim's interface is a command line simulation. You control it by entering commands like you might in a terminal. The space of possible commands is infinite and flexible--limited only by your imagination--so go wild.
Those commands act as prompts for the simulator: "Simulator Claude." Telling it how to find, alter, direct, etc the person you're simulating. If you don't know what to do, just hit return, and "Searcher Claude" will step in to guide the current sim. Or use the /help command for some generative inspiration.
To begin, enter any name (e.g. Socrates, Zaphod, the xenomorph). Then the /locate command will run automatically, and after that you're ready to steer. If the sim isn't going the way you want, just alter it! Hard refresh if you hit a bug.
Join us in Discord to swap sims, screenshots, & ASCII art.
Enjoy surfing the multiverse of identities...

(Sign-up for updates here)
Honcho
If LLMs can simulate infinite identities, then they're uniquely suited to simulate you. You in any moment, setting, frame of mind contained in the complexity that is your ever-changing identity.  
If you're building an AI app, that's the level of personalization now possible. But you've got your vertical-specific tasks to focus on, going down this clearly wacky identity rabbit hole to would be redundant and inefficient.
Join >100 projects already on the private beta waitlist for Honcho's self-improving user memory.


(And if you want to work full time on the bleeding edge of human & machine cognition, get in touch...)

---

### Cope is the canary, but context is key (for the end of software)

Why context is the key to the end of software--how user identity modeling will bridge the gap between AI capabilities & truly personalized experiences.

Date: 2024-06-01
URL: https://blog.plasticlabs.ai/notes/Cope-is-the-canary,-but-context-is-key-(for-the-end-of-software)
Tags: macro, honcho, philosophy, notes

Cope Is the Canary, but Context Is Key (for The End of Software)
The End of Softwaret.co/JWg6QYqLzO— Chris Paik (@cpaik) May 31, 2024 

Many reactions to Chris Paik’s prescient The End of Software carry a distinct signature that readers of the Pessimist's Archive will recognize instantly--cope.
Cope-y outbursts like this are almost always a canary in the coal mine. As technologists, we’re quick to notice the defensive, rationalizing outcry that accompanies the eve of disruption. But like everyone else, it’s hard to notice when it’s coming for you. When you’ve got skin in the game.
It’s easy for us to see that creators denouncing the quality of image generators or English teachers asserting LLMs “only produce bad writing” herald the advent of serious change. If there were no threat, there’d be no negative reaction. They might be right…right now, but it’s only a matter of time (and market forces). No doubt they too can laugh at the historical examples of this in other groups disparaging stuff we all love and take for granted today. 
The key thing to notice is that both positions can be true. New technology often does suck, but it also often gets way, way better. So much better that we can fully dispense with yesterday’s drudgery for tomorrow’s opportunity.
Yet the ways in which the fresh tech sucks today form the roadmap to the ways it will be awesome in the future. It’s a mistake to say the problem is solved and a mistake to say it won’t be solved.
Chris is right that AI is coming for software like the internet came for journalism1. But he’s making a predictive macro argument. And he’s not saying this is a done deal. Similarly, those arguing that how they do software development is more complex than what LLMs are currently capable of are right...but again, not a done deal. If the solution was complete, we’d be on to arguing about the next thing.
So what’s missing? What roadmap can we learn from the cope that gets us to disruption? What do LLMs lack and software engineers have that’s critical to translate ideas and natural language into applications?
At Plastic, we think it’s context. Not just context on how to do a general task, like writing code, but your context. How you would write the code? Why would you write it that way? What made you that person?
To know this--to bridge the gap--LLMs need access to a model of your identity. How you solve a technical problem is about more than just your technical knowledge. It’s about all the elements of your identity and psychology and history that inform how you synthesize unique solutions. That’s why we’re building Honcho.
And to realize a future replete with trusted autonomous agents working across diverse domains on your behalf reliably--as true extensions of your agency--we’ll need Honcho too.
the latent space contains all possible identities pic.twitter.com/cWO6ovRJnN— Courtland Leer (@courtlandleer) June 5, 2024 
Footnotes


There is a distinction to be made re: the piece's comparison between computer science & journalism degrees. Journalism is actually more like software engineering here, & computer science like language. Lang & cs will remain useful to study, but the journalism & engineering trade degrees built on top of those primitives need a serious refresh to be worthwhile. I.e. it’s a good idea to have aptitude with symbolic systems & abstract technical knowledge, but application & execution will change as technology evolves. ↩




---

### Context window size doesn't solve personalization

Why infinite context windows won't solve AI personalization without mechanisms to transfer personal context & discern what's important for generation.

Date: 2024-05-11
URL: https://blog.plasticlabs.ai/notes/Context-window-size-doesn't-solve-personalization
Tags: notes, ml

There are two reasons that ever increasing and even functionally infinite context windows won't by default solve personalization for AI apps/agents:


Personal context has to come from somewhere. Namely, from your head--off your wetware. So we need mechanisms to transfer that data from the human to the model. And there's a lot of it. At Plastic we think the path here is mimicking human social cognition, which is why we built Honcho--to ambiently model users, the generate personal context for agents on demand.


If everything is important, nothing is important. Even if the right context is stuffed in a crammed context window somewhere, the model still needs mechanisms to discern what's valuable and important for generation. What should it pay attention to? What weight should it give different pieces of context in any given moment? Again humans do this almost automatically, so mimicking what we know about those processes can give the model critical powers of on-demand discernment. Even what might start to look to us like intuition, taste, or vibes.


All that said, better and bigger context window are incredibly useful. We just need to build the appropriate supporting systems to leverage their full potential.

---

### The model-able space of user identity is enormous

The vast untapped potential of modeling user identity with LLMs--going beyond behavioral data to semantic understanding of values, beliefs, & desires.

Date: 2024-05-11
URL: https://blog.plasticlabs.ai/notes/The-model-able-space-of-user-identity-is-enormous
Tags: notes, ml, cogsci

While large language models are exceptional at imputing a startling amount from very little user data--an efficiency putting AdTech to shame--the limit here is vaster than most imagine.
Contrast recommender algorithms (which are impressive!) needing mountains of activity data to back into a single preference with the human connectome containing 1400 TB of compressed representation in one cubic millimeter.
LLMs give us access to a new class of this data going beyond tracking the behavioral, toward the semantic. They can distill and grok much 'softer' physiological elements, allowing insight into complex mental states like value, belief, intention, aesthetic, desire, history, knowledge, etc.
There's so much to do here though, that plug-in-your docs/email/activity schemes, user surveys are laughably limited in scope. We need ambient methods running social cognition, like Honcho.
As we asymptotically approach a fuller accounting of individual identity, we can unlock more positive sum application/agent experiences, richer than the exploitation of base desire we're used to.

---

### ARCHIVED: A Comprehensive Analysis of Design Patterns for REST API SDKs

A deep dive into SDK design patterns, comparing object-oriented vs singleton approaches & evaluating code generation platforms for API client libraries.

Date: 2024-05-09
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-A-Comprehensive-Analysis-of-Design-Patterns-for-REST-API-SDKs
Tags: blog, dev, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post contains Vineeth's (Plastic's Co-founder & CTO) notes on REST API SDK design patterns that informed how we built Honcho's client libraries. Some patterns described here have been superseded by our shift toward LLM-native interfaces, but the analysis of pagination, error handling, & developer experience remains useful for anyone building API tooling.
For the most up-to-date SDK reference, check out the Honcho Docs.
Enjoy.


This post is adapted from vineeth.io
TL;DR
After several months of managing the SDKs for Honcho manually, we decided to
take a look at the options available for automatically generating SDKs.
From our research we picked a platform and have made brand-new SDKs for Honcho
that use idiomatic code, are well documented, and let us support more languages.
Introduction
For the past few months I have been working on managing the Honcho project and its associated SDKs. We've been taking the approach of developing the SDK manually as we are focused on trying to find the best developer UX and maximize developer delight.
This has led to a rather arduous effort that has required a large amount of
refactoring as we are making new additions to the project, and the capabilities
of the platform rapidly expand.
While these efforts have been going on a new player in the SDK generation space
dropped on hacker news.
When I first started working on Honcho I did a cursory look at a number of SDK
generators, but wasn't impressed with the results I saw. However, a lot of that
was speculative and Honcho was not nearly as mature as it is now.
So spurred by the positive comments in the thread above I've decided to do a
more detailed look into the space and, also try to develop a better understanding
of what approaches are generally favorable in creating API client libraries.
Background
For a full understanding of Honcho I recommend the great Simple Honcho Primer post, but I'll try to summarize the important details here.
Honcho is a personalization platform for LLM applications. It is infrastructure
that developers can use for storing data related to their applications, deriving
insights about their data and users, and evaluating the performance of their
applications. This functionality is exposed through a REST API interface with
the following resource constructs.
|____Apps
|____|____Users
|____|____|____Sessions
|____|____|____|____Messages
|____|____|____|____Metamessages
|____|____|____Collections
|____|____|____|____Documents
So Apps have Users that have Sessions and Collections where Sessions can have
Messages and Metamessages and Collections can have Documents.
At the time of writing this post Honcho is being manually maintained with a
singular client SDK for the Python ecosystem. The SDK is co-located in the
repo.
The SDK is written in an object-oriented style where the top level Honcho
object will return lower level objects such as a User object and Session
objects. These objects contain the CRUD methods necessary to use them i.e.
from honcho import Honcho
 
honcho = Honcho("Test App Name")
honcho.initialize()
 
user = honcho.create_user("username")
session = user.create_session()
There is an Async version of the SDK with an AsyncHoncho class that uses
objects such as AsyncSession and AsyncUser.
Guiding Questions
Before evaluating the below platforms I wanted to investigate a few questions I
had about how to design SDKs and how they are generally maintained in other
organizations. I've also included some questions I want to think about when
looking at the different platforms
I'm doing this through the lense of a Python developer as Honcho currently only
has a Python client library with plans to quickly expand to other ecosystems.
General SDK Questions

Do developers prefer an object-oriented approach or singleton approach for
client SDKs that wrap a REST API?
What additional features are generally important in SDK design outside the
functionality of the API (retry, pagination, etc.)?

Platform Specific Questions

How readable and easy to understand is the generated code?
How customizable is the end result?
How easy was it to use the tool?
What approach does the tool take? Object-oriented or singleton?
How does it handle async vs sync interfaces?

Research

First I took a look at sources and posts onlines that talk in general about
developing SDKs. This isn't an exhaustive look at every link I looked at, but
ones I thought were relevant. The notes are messy and not necessarily fully
formed sentences.

Any design patterns and tips on writing an API client library
Things they are laying out here.
One person

Auth is really hard to figure out
Retry logic and pagination is really important

Another person

Keep data objects as just data and use other objects for transformations

^ basically advocating for the singleton model
Person 3

Also arguing for singleton approach. Made a good case where if you really only
care about lower level stuff it's annoying

Firstly, don't go over the top with object-oriented modelling. If you've got an API call like:
GET /locations/12345/customers/65432/orders/87678768
Don't implement this as:
client.location(12345).customer(65432).order(87678768).get()
Just implement:
client.get_order(12345, 65432, 87678768)
that last one is better tbh it's just managing that data isn't done within the
object, which is my main problem.
So arguments for singleton approach are

harder to go to lower levels from the start

The object-oriented approach looks more readable.
A Design Pattern for Python API Client Libraries
It mainly covers how to build an singleton library but has this one snippet at
the end.

Other types of APIs
This pattern works well for RPC-style APIs, but tends to break down for more
object-based or RESTful APIs as having a single interface class gets messy
quickly. In those cases I find it makes more sense to break the interface down
to resource-level, modeling things more like an ORM. I'll cover that in a later
post, next time I find the need to build one.

At the time of this research there was no follow-up post.
Ask HN: Best practices (and examples) for designing client libraries for APIs?
The first comment actually advocates for an object-oriented model but just using
the top level client object for authentication and setup stuff.
Most of the sentiments kind of make me think using an object-oriented model
might make more sense.
How to design a good API and why it matters
Nothing really to note from there. It's more about the API itself and not the
SDK.
Building A Creative & Fun API Client In Ruby: A Builder Pattern Variation
This is basically a guy who saw an singleton approach and said I want an object
oriented approach.
How to design your API SDK
A developer from twilio talking about their approach to creating helper
libraries and client libraries.
A point he makes is that "If you've designed your API in a RESTful way, your API
endpoints should map to objects in your system"
This point isn't explicitly asking for the object-oriented approach as the
singleton approach just moves the verbs to the singleton, but usually still has
data only objects for the different resources.
I say this, but the examples seem to use an object-oriented model.
How to build an SDK from scratch: Tutorial & best practices
Written by one of the SDK generation platforms.
It talks in general terms about creating data objects and mapping methods to
endpoints. One of the points is suggests as a good grouping method is to group
functions in service classes, essentially advocating for an object-oriented
model.
Designing Pythonic library APIs
The two takeaways that are the most important to me when looking at these are

Design your library to be used as import lib ... lib.Thing() rather than from lib import LibThing ... LibThing().
Avoid global state; use a class instead

From that it seems using a singleton for the actions/verbs and then storing data
in dataclasses would support both of the requirements. The examples in the post
show a class that has functionality.
Using tree-shaking style imports should also allow for lower scopes. For example
when only worrying about messages for a particular session in honcho a user
could import just the messages namespace i.e.
from honcho.apps.users.sessions import messages
 
messages.create("sample")
so there are pythonic ways to make the code less verbose. However the benefit of
having the entire string is making it clearer what messages are being discusses.
Are these Honcho mesages? LangChain messages? It can get messy that way
especially in the LLM space where many libraries and components are
converging on similar naming schemes.
Build a Python SDK
Looks like a guide made by Cisco. I paid special attention to the "API Wrapper
Module" section. It was a really barebones example in this guide that just
implemented a very small client and put most of the attention on how to manage
the connection logic.
It used one singleton object that had all the methods available for the API.
There was no concept of resources or data objects here as no data was being
persistently stored.
How to build a user-friendly Python SDK
Noticing the trend of abstracting all connection logic for http requests to a
separate module and having reusable methods for different http functions.
Main focus of the post was just on good practices of documentation, testing, and
logical organization.
SDKs.io
A more comprehensive repository of thoughts and principles around SDK design.
Made by APIMATIC. which seems to be another player in the code generation space.
I paid special attention to the Build section under Best Practices, and
specifically the endpoints to methods and the models & serialization.
They state putting all methods in a single class (singleton) has the advantage
of reducing the need to initialize classes, but can make the class size very
large if there are many endpoints.
Grouping methods into different namespaces could probably remove this problem
too. A nested singleton can reduce the confusion, while still not needing to
mess with classes and objects.
It generally seems popular to at the very least create types and data objects
for handling and storing API responses. They help with readability, type hints,
data validations, etc. Regardless of the singleton or object-oriented approach
data objects are something that should probably still be included.
Generating SDKs for your API
Advocates for using generators for making SDKs and talks about how different
languages have different idioms and conventions that will be hard to manage.
Also mentions having the generator create data models.
Guiding Principles for Building SDKs
Some key insights

Make sure documentation is very comprehensive
Try to minimize external dependencies
Have modular design patterns that make it easy to extend and pick and choose
features.

Should I implement OOP in a REST API?
Most people seem to be saying a full OOP method is overkill, but there are
people advocating for having a controller class with methods that take data
objects as inputs. Essentially advocating for the singleton approach with data
only objects.
Analysis
Many of the generic concerns of SDK design do not have to do with the UX of the
SDK for the end developer, rather background processes that an SDK handle. This
includes:

Authentication
Retry Logic
Pagination
Logging

When it comes to the actual developer experience and interfaces for interacting
with the SDK the community seems a bit split. This is very much because of the
boring fact that REST APIs are designed very differently and so it depends on
the specifics of the API.
Some APIs have many resources with basic CRUD operations. Others have many
different endpoints, but only have a few resources. The singleton architecture
vs a strict object-oriented approach again seems to depend a lot. Some sources
advocate for a strict object-oriented approach where classes have their own
methods, while others advocate for a singleton approach stating objects are
overkill.
However, the singleton approach doesn't completely abandon the idea of objects
and almost always advocates for data objects, or some kind of models that can be
used for type hints and validation.
There is some tradeoff regardless with problems arising at different levels of
scale. The singleton approach could be verbose and cumbersome at smaller scales,
but the object-oriented approach may not be a readable, and it could be unclear
what methods are doing in complex codebases. Even GPT-4 couldn't decide between
the two.

Again and again, the best way to approach SDK development is to just do whatever
is easier, and create tons of documentation that will help developers navigate
your API Ladder. Someone will get confused regardless of what you do, so the key is to make sure the SDK makes sense (even if it's not the most efficient or clean) and remove hurdles for users to navigate errors and mistakes.
SDK Generation Platforms
With a sense of the best standards for SDK design and additional features that
should be supported in the SDK I want to look at a few different options to
determine what is the best solution to go with.
Below is a list of the different platforms I wanted to review

Stainless
Speakeasy
liblab
OpenAPI-Generator

I was using the OpenAPI Spec for Honcho that was housed at
demo.honcho.dev/openapi.json.
Stainless
Since the hacker news thread for the release of stainless is what spurred this
research I decided to try them out first.
From their web portal they were able to take a link to the OpenAPI spec and
generate a NodeJS and Python SDK immediately. There was no tweaking or anything
necessary.
I mainly paid attention to the Python SDK. The code was very readable and made
sense. I also liked how it used httpx and pydantic by default and made an
async version of the interface. They took the singleton approach to the design
of the interface. There was also built-in capabilities for retries, pagination,
and auth.
There's also capability for adding custom code such as utility functions.
Speakeasy
Speakeasy required me to do everything locally through their brew package. It
did not immediately accept the OpenAPI Spec and required me to make some tweaks.
These were low-hanging fruit, and their cli has a handy AI tool that will
diagnose the issue and tell you what to fix.
I just had to add a list of servers and deduplicate some routes. I'm happy it
found these errors, but there was some friction for me to get started. Stainless
just worked out of the box and made some logical assumptions.
The generated SDK didn't feel as strong as the stainless one. There didn't seem
to support async methods, it did not use pydantic and used the built-in
Python @dataclass. The methods had really unwieldy names, and looked like it
would need a lot of tweaking to get it more production ready.
Liblab
Also had me do the generation from the cli using their npm package. It was
pretty straightforward to login and give it an API spec. Liblab seems to require
a lot tweaking to get better results. It gave me several warnings asking me to
add tags to my API Spec. I did not add them and went ahead to look at the
generation.

I'm not opposed to adding the tags if necessary, but I was able to get good
results without adding them on other platforms.

The results were also lack luster. The SDK took the singleton approach as well,
which seems to be the industry standard for codegen tools. The method names
were also unwieldy. It also didn't make use of pydantic and instead implemented
its own BaseModel class. It was built on the requests model and doesn't seem
to support async methods.
OpenAPI Generator
This is the only one on the list that is not expressly backed by a company
whose main goal is SDK generation. It is however a very popular project with
many sponsors.
Again, I tried to generate a client from the cli using their npm package. I used
version 7.5.0 and once again gave it my API Spec. It gave a few warnings about
OpenAPI Spec v3.1 not being fully supported yet, but generated a package either
way.
I again was not too impressed with the results, however I did like it more than
liblab. The method names were also unwieldy, and the project relies on urllib3.
I did not see an indication of support for an async client.
The repo did use pydantic for typing and data classes, which is a plus.
Once again, the sdk use the singleton approach.
I also did not see any indication of functionality for retry logic,
authentication, or pagination.
Conclusion
Overall, Stainless had the results that I liked the most. With almost no work
from me, it produced a high quality SDK that designed things in a sensible way
with many built-in features such as retries, pagination, and auth.
All the platforms took the singleton approach with a host of data models so
there isn't much to compare in that regard.
The other platforms did not produce anything unusable, but they seemed to use
less modern features and require a lot more massaging to get a desirable result.
The docs for stainless also looked more clear, and it seems easier to add
customizations after the fact.
I will give Speakeasy some kudos for having documentation for different API
frameworks. The FastAPI one made it easy to figure out what I needed to tweak
and how to do it. The AI debugging feature was also a nice help.
What I'm looking for right now is the platform or tool that can reduce my work
the most and let me focus on other things and stainless achieved that. The
results are not perfect, but it doesn't look like it'll need more than some
slight tweaking and testing to get to a state I want.
Results
After reaching the conclusion in the previous section, I took some time to fully
implement Stainless to make SDKs for Honcho and am proud to announce the release
of a new Python SDK, and the launch of a brand-new NodeJS SDK.
Both of these SDKs will be in separate open source repositories.

Honcho Python SDK
Honcho TypeScript SDK

Honcho will soon be available for a wide range of ecosystems and platforms,
making it even easier and more accessible to make personalized agents.

---

### ARCHIVED: Introducing Honcho's Dialectic API

Announcing the Dialectic API--an LLM-native endpoint enabling agent-to-agent chat in natural language for dynamic user personalization.

Date: 2024-03-26
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-Introducing-Honcho's-Dialectic-API
Tags: dev, ml, announcements, blog, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post announced Honcho's Dialectic API--an LLM-native endpoint for just-in-time agent-to-agent context queries in natural language. This endpoint has since evolved into the much more powerful .chat method in Honcho today. The Dialectic API was ahead of its time, and its successor remains state-of-the-art.
Here we lay out the reasoning behind the development of this feature. We get into the case for natural language as a substrate for agent coordination, the argument that rigid API specs constrain what's now possible, & a vision of agents collaboratively reasoning about how to personalize UX--all thinking that's shaped everything we've built since.
Enjoy.



TL;DR
Our Dialectic API is an LLM-native way for your AI application to discuss user context with Honcho. It allows for direct LLM-to-LLM communication in natural language.
Agents need ways to interface dynamically and autonomously, free from the rigidness of traditional APIs. We're building that substrate.
What's a Dialectic API?
Honcho is our platform for personalizing agents to users. Currently, it includes session storage, BYO context storage, passive theory of mind user modeling, and now an agent deeply coupled to all of that rich user context. That agent can be called via our Dialectic API to surface user data for use with any cognitive architecture.
How It Works
In designing an LLM pipeline and an application's cognitive architecture, you'll need to decide where and how to inject personal user context so the task is not simply completed in a general way, but in the most appropriate way for each specific user.
That's when your agent asks Honcho for what it needs in natural language. This query can take many forms. Some possibilities:

A single or list of question(s) about the user
A prompt fed to Honcho to hydrate with personal context
A user insight to inject directly into a prompt
A custom while loop to gather context from Honcho until some condition is met
A personalized revision of a potential user response
A theory of mind prediction about the user's state or behavior
A user context query to cache for later use
A list of Honcho-derived facts about the user so far in the session
A list of reasons why the user is behaving a certain way
A static fact about user identity
A piece of user data to use in improving your app's overall vertical or user-specific service

Key to note here is the ability to hard code the most useful type of Honcho query for your app's use case or--better yet--to trust your agent to reason autonomously about what it needs based upon the current session (or any other criteria) and feed that to Honcho. Or run a hybrid approach. This can be done synchronously with an inference/session or async as needed.
In this way, Honcho becomes an self-improving oracle to the identity of each and every one of your app's users. Any agent can chat with a representation of a user (as Honcho) on the backend.
Honcho responds to queries in the same format--natural language. Most simply, this is just a conversation between two agents, collaboratively reasoning about the best way to personalize UX. Agent-to-agent chat over users.
In the coming weeks, we'll release a number of off-the-shelf options to plug into any cognitive architecture and demos to illustrate more custom utility. We expect to see (and are already seeing in our private beta) many novel ways to prompt Honcho effectively.
Why We Built It
Why is a dialectic API the right way to solve the problem of user context in LLM applications?
Not only is it ideal from a development and design perspective, it's optimal for the particular task of personal context and user identity.
The DevEx Case
^a14c2f
Our Dialectic API is single endpoint for everything personalization.
It reduces development overhead and allows you to get a personalized application running quickly and efficiently--speedrunning to production.
For most AI apps, personalization will be a key differentiator between your agent and ever more capable foundation models. But setting up a RAG pipeline to manage all your user data--much less transform that into a useful representation of each user--is a laborious and significant R&D investment. Honcho is a ready-made, plug and play solution.
Further, when agents can communicate directly using natural language, there's no need to learn and manage complicated API specification. Or for us to build it. Since LLMs are proficient at interpreting the intricacies of natural language, there's a functionally infinite number of ways to ask Honcho a question and get a satisfactory result. Far superior to brittle and strict legacy APIs.
However, this doesn't mean the developer now needs to be a prompting expert, fluent in all its esoterica. Honcho is an expert in personal context and theory of mind reasoning, so your prompts can be adaptive and ad hoc, and Honcho will figure out the rest. When you're ready, you can even offload the queries to your app-side LLM.
The ML Case
^x7f7f8
Extra context improves user response generation, the more specific, the better. Focus on ML to crush your vertical, let Honcho personalize it by default.
Leverage Natural Language Plasticity
Each user has a rich and complex personal identity.  Access to higher-fidelity representations of that identity can be combined with the task completion context of your app in each moment to generate the most optimal tokens for each user-agent interaction. I.e. ones that are felt by the user to be more personalized and satisfactory--enhancing the real and perceived time to value ratio of your app.
But that complexity is hard to capture and needlessly constrained with typical API design. In order to express the nuance of personal context, we need the high variance, dynamic nature of natural language.
Because LLMs consider tokens in relation to a vast human narrative space, we're much closer to semantic machine understanding than ever. Personal context allows you to target parts of the latent space most useful in generating tokens for specific users in specific settings. The only way we know to communicate and leverage that depth is with the inherent diversity of natural language...which is itself evolutionarily optimized to describe human identity well.
Way richer than running RAG over a vector store of session logs. Or stateless CRUD-inspired API spec.
Out-Compete Foundation Models
Honcho's Dialectic API also allows you to build training examples with rich theory of mind context. Those datasets can help you outperform foundation models in your specific vertical and its set of tasks.
By adding additional context to inputs, the distribution of responses your model samples from can be improved. Any sort of "reasoning" the language model exhibits in a single inference is due to learned patterns in the dataset. So if you can create examples that can help it learn better patterns, you can improve the "reasoning" steps it exhibits.
Ultimately, we're learning ways of responding that foundation models won't. Using theory of mind context yields more specific examples, which allows more robust domain-specific training.
Why "Dialectic"?
In the classical sense, a dialectic process is one where two parties seek to arrive at the truth via reasoned dialogue.
(In our case, the truth is a solution for delivering the optimal per-app, per-user, per-session experience.)
We've termed our API this way because not only is it communication between software systems, but it's a reasoned discourse between agents to reach the ideal conclusion.
Each agent has a different set of information, the free discussion allows them to eliminate that asymmetry and arrive at a synthesis greater than its parts. One agent is expert in delivering a service in its vertical, the other in modeling user identity and surfacing relevant, timely context based on that representation.
The Agentic Substrate
Our Dialectic API is part of an evolutionary lineage. One that records humanity's slow discovery of all the ways machines can communicate with one another--from telegraph and punch cards to REST and GraphQL. Along each axis of typical machine comm improvement, agent-to-agent dialectics offer advantages:

Speed - user time to value can be optimized with granular personal context requests
Complexity - natural language, being more expressive, is capable of capturing highly specific user states and predictions
Efficiency - ask for precisely what you need, inject exactly where you need it
Security - re-centralizing user identity with Honcho disincentivizes user modeling on a per-app basis
Standardization - natural language is universal to humans and LLM-powered synthetic agents, as is the narrative space those parties draw from
Fault Tolerance1 - instead of just throwing errors, LLM agents can either figure out any confusion or simply ask for clarification

As the commodification of inference and intelligence is coupled with growing general foundation model capability, application developers will naturally be pushed toward greater and greater vertical specificity. This will drive the development of increasingly atomic agents, ones who excel at a very narrow tasks.
This explosion of such agent micro-services, will have to include the evolution of systems for agent-agent communication and transaction. If agents are going to collaborate and get shit done for us, they need native ways to communicate. Beautifully, LLMs share with us and among themselves the universal interface of natural language.
We can leverage this substrate for agent coordination with more depth and nuance than fragile trad API design. Doubtless, categories of agents will find more efficient symbol structures for cooperation in specific, repetitive cases. But discourse in natural language always remains available as a rich foundational protocol. And as we've explored, it's the ideal starting place for transmitting insights about human identity.
This is just the start. Just like you can appendage memory and tools to an LLM, we can augment this substrate in a number of ways--from designing multi-party protocols, to enabling zero knowledge or confidential environments, or recording transactional data on blockchains or other types of public or private immutable ledgers.
That kind of richness puts us one step closer to the dream of a semantic web, one as replete with meaning as the physical world and machine grokable. What matters to me can be used to personalize an atomic agent just in time, without sacrificing important context. Intelligent micro-services can be more aligned with me than human economic actors and professional services, which are plagued with high-latency interest misalignment and information asymmetry.
Honcho and agent dialectics can eliminate the principal-agent problem for this new economic paradigm, digitally extending human agency and identity further than ever before.
Private Beta
Our Dialectic API is now available in private beta.
If you're excited build with a hosted version of Honcho and explore the ideas covered here, sign-up for our waitlist.
And in the meantime, join our Discord and tell us what you're working on!
Footnotes


Our friend Neel Baronia calls this a "Squishy API" & has thought a lot about the business model implications ↩




---

### Humans like personalization

The case for AI personalization--why users prefer bespoke experiences & how apps that don't personalize will lose to those that do.

Date: 2024-03-26
URL: https://blog.plasticlabs.ai/notes/Humans-like-personalization
Tags: notes, philosophy

To us: it's obvious. But we get asked this a lot:

Why do I need to personalize my AI application?

Fair question; not everyone has gone down this conceptual rabbithole to the extent we have at Plastic and with Honcho.
Short answer: people like it.
In the tech bubble, it can be easy to forget about what most humans like. Isn't building stuff people love our job though?
In web2, it's taken for granted. Recommender algorithms make UX really sticky, which retains users sufficiently long to monetize them. To make products people love and scale them, they had to consider whether billions--in aggregate--tend to prefer personalized products/experiences or not.
In physical reality too, most of us prefer white glove professional services, bespoke products, and friends and family who know us deeply. We place a premium in terms of time and economic value on those goods and experiences.
The more we're missing that, the more we're typically in a principal-agent problem, which creates overhead, interest misalignment, dissatisfaction, mistrust, and information asymmetry:



But, right now, most AI applications are just toys and demos:
Transclude of ARCHIVED;-Honcho;-User-Context-Management-for-LLM-Apps#^18066b
It's also why everyone is obsessed with evals and benchmarks that have scant practical utility in terms of improving UX for the end user. If we had more examples of good products, ones people loved, killer apps, no one would care about leaderboards anymore.

OK, but what about services that are purely transactional? Why would a user want that to be personalized? Why complicate it? Just give me the answer, complete the task, etc...

Two answers:

Every interaction has context. Like it or not, people have preferences and the more an app/agent can align with those, the more it can enhance time to value for the user. It can be sticker, more delightful, "just work," and entail less overhead. (We're building more than calculators here, though this applies even to those!)
If an app doesn't do this, it'll get out-competed by one that does...or by the ever improving set of generally capable foundation models.


---

### LLM Metacognition is inference about inference

Defining metacognition in LLMs as running inference on prior inference outputs--a critical architecture for building rich user representations.

Date: 2024-03-26
URL: https://blog.plasticlabs.ai/notes/LLM-Metacognition-is-inference-about-inference
Tags: notes, ml

For wetware, metacognition is typically defined as ‘thinking about thinking’ or often a catch-all for any ‘higher-level’ cognition.
(In some more specific domains, it's an introspective process, focused on thinking about exclusively your own thinking or a suite of personal learning strategies...all valid within their purview, but too constrained for our purposes.)
In large language models, the synthetic corollary of cognition is inference. So we can reasonably define a metacognitive process in an LLM architecture as any that runs inference on the output of prior inference. That is, inference itself is used as context--inference about inference.
It might be instantly injected into the next prompt, stored for later use, or leveraged by another model. This kind of architecture is critical when dealing with user context, since LLMs can run inference about user behavior, then use that synthetic context in the future. Experiments here will be critical to overcome the machine learning community's fixation on task completion. For us at Plastic, one of the most interesting species of metacogntion is theory of mind and mimicking that in LLMs to form high-fidelity representations of users.

---

### Achieving SOTA on OpenToM with DSPy

How we achieved state-of-the-art results on the OpenToM theory-of-mind benchmark using DSPy to learn few-shot examples with GPT-3.5-turbo.

Date: 2024-03-21
URL: https://blog.plasticlabs.ai/research/Achieving-SOTA-on-OpenToM-with-DSPy
Tags: ml, blog, research


TL;DR
We used DSPy to achieve SOTA results on the OpenToM benchmark using gpt-3.5-turbo. The benchmark's creators suggest language models fall short when modeling mental states and psychology, but we find using DSPy to learn few-shot examples leads to significantly outperforming all the models tested (gpt-4-turbo included) along this precise axis.
The fact you can learn few-shot examples to make a small, fast model perform just as well on a task as a large, slow one is significant. This signals to us a need to broaden the scope of methods for evaluating Theory of Mind capabilities in LLMs, because the social cognition needed to build great products goes far beyond just answering questions about stories.
The OpenToM Dataset
On February 14th, 2024 a paper dropped on ArXiv introducing the OpenToM benchmark: a new dataset to use for evaluating Theory of Mind (ToM) in Large Language Models. ToM evals are typically borrowed from developmental psychology and consist of character-driven scenarios. The language model is asked to answer questions about various aspects of the characters' mental states. This ability has traditionally been thought of to be uniquely human (or limited to a very few species), but language models are starting to exhibit some level of proficiency in this task as well.
The authors of this paper point out how the characters in existing datasets lack personality traits or preferences, along with motivations for their actions. To remedy this, they devised a generation pipeline that does the following:

Endows characters with preferences and personality traits
Generates intentions and the corresponding actions
Uses an LLM to produce the narratives/stories
Revises and refines those stories using human annotators

The questions in the dataset seek to cover characters' mental states of both the physical world (e.g., the location of an object) and their psychological states (e.g., character's attitude towards a particular action). They test some of the most popular LLMs on these questions and find that they perform well on the questions that ask about the physical world but "fall short" when asked about characters' mental states.
There are three different "genres" of questions with different levels of "granularity".


Attitude: questions about the characters' attitude


Location: questions regarding the location of an entity


MultiHop: questions composed by adding an additional reasoning hop on top of the Location questions


Within Location there are coarse and fine questions and within both Location and MultiHop there are first order and second order questions.

Coarse: asks about the characters' perception of whether an entity is at its initial location
Fine: inquires about the entity's explicit location
First Order: directly asks about a character's perception of the world
Second Order: inquires about a character's belief of another character's mental state

In the ToM space, there is really only one prompting technique that has shown improved results over Chain of Thought (CoT) called "SimToM" (Wilf, et al), which is a two-stage prompting framework to re-phrase the narrative through the perspective of the subject in question. CoT and SimToM are the only two tested against the dataset in the paper.
Experiments with DSPy
What makes the DSPy package interesting is the ability to abstract away the underlying prompts and examples if the task and metric are well defined. Anecdotally, we believe that LLMs are quite good at the psychological modeling the OpenToM authors suggest they "fall short" on. So we asked ourselves, "what if we could learn the prompts and examples to optimize performance on this benchmark?"
This task is relatively easy to define in DSPy terms: (context, question -> answer). This guide was helpful in crafting our modules which can be found here. The authors of the OpenToM paper also released extensive evaluation code which we leveraged heavily for parsing the LM's answers and assessing them.
We conducted the following experiments:

Learn few-shot examples with the BootstrapFewShotWithRandomSearch optimizer and gpt-3.5-turbo with CoT prompting
Do the same but use gpt-4-turbo as the "teacher" LM to learn the examples
Learn system prompts with the SignatureOptimizer and the BayesianSignatureOptimizer

Obviously there is much more we could have done, so if you're reading this and you have the time (and inferencing budget) to run more comprehensive experiments, get in touch — we'd love to help!
Results
The findings of our experiments were mixed but promising. We found that the only experiment that showed positive results was compiling a CoT-prompted gpt-3.5-turbo module with the BootstrapFewShotWithRandomSearch optimizer. Both of the signature optimizers and gpt-4 as a teacher in  BootstrapFewShotWithRandomSearch didn't have much of an effect.
Our full experiment amounted to roughly $300 in inference costs, running 50 training examples on 25 candidate programs. We evaluated performance the same way the paper did, by randomly sampling 50 examples from a hold out set in 5 batches and computing average F1 scores. You can view our forum discussion in the DSPy Discord here.
The following table shows our results from experiment number one compared to the paper's CoT-prompted results (found in Table 3 in the paper):





























































questionmixtralgpt-3.5-turbogpt-4-turbocompiled-BFSWRS-3.5-turboLocc​(F)0.7840.5870.9420.89Locc​(S)0.5390.4570.8280.791Locf​(F)0.3010.4690.450.303Locf​(S)0.180.240.1870.476MHop(F)0.610.5470.8350.64MHop(S)0.5510.4140.7550.429Att0.5190.4460.580.558
On most of the question types, we see CoT-prompted gpt-3.5-turbo compiled with BootstrapFewShotWithRandomSearch examples outperforms both CoT-prompted base gpt-3.5-turbo as well as mixtral, and comes close to gpt-4-turbo performance — which is quite impressive! The exceptions here are fine, second-order location questions (which outperform gpt-4-turbo 🥳) and fine, first-order location questions (which underperform gpt-4-turbo). Due to budget constraints, we only tested gpt-3.5-turbo.
What's particularly interesting is the performance on the fine, second-order location questions (Locf​(S)). As a reminder, second-order questions inquire about a character's belief of another character's mental state. This is the exact type of question the OpenToM authors claim that LMs perform poorly on, yet we saw that with our learned few-shot examples, it outperforms all of the other language models significantly.
Analysis of Augmented Examples
The augmented examples from the compiled modules seem to mimic the format of the stories within each question type/granularity. You can see all of them on GitHub, but here are two examples:
Attitude:

"Paxton and Anderson were two individuals with contrasting preferences when it came to socks. Paxton despised them, finding no use or appeal in these fabric foot coverings, while Anderson, on the other hand, had a deep affection for them. It was a peculiar disagreement that seemed to set them apart.\n\nOne day, destiny led them both into a confined space - the closet. Paxton entered first, followed closely by Anderson. As they looked around, their eyes landed upon a box placed on one of the shelves. To their surprise, the box contained an assortment of colorful socks. A display that delighted Anderson, but only fueled Paxton's annoyance further.\n\nAfter a brief moment, Anderson decided to leave the closet, unaware of Paxton's ulterior motive. Paxton, being a negativistic person, was determined to eradicate the presence of socks from Anderson's life. Seizing the opportunity, Paxton swiftly moved the socks from the box to the nearby trash can. The act was done discreetly, ensuring Anderson did not witness this secretive disposal.\n\nAnd just like that, the story came to an abrupt end. The socks lay in the trash can, while Anderson remained oblivious to Paxton's actions. The tale of clashing opinions had taken an unexpected turn, leaving a trail of unanswered questions about the fate of the socks and the impact it would have on their peculiar relationship."

MultiHop:

"Connor and Ryker were two best friends who shared a common liking for raincoats. They loved the feeling of wrapping themselves up in the cozy, waterproof fabric whenever it rained. One day, as Connor entered the sunroom, he noticed that the raincoat they usually shared was neatly placed in a bucket. To his surprise, Ryker was already in the sunroom, his eyes fixed on the raincoat.\n\nConnor, being a considerate person, realized that they both liked the raincoat and should make sure they didn't forget it on rainy days. With that thought in mind, he quietly moved the raincoat from the bucket to the front door hook. This way, it would serve as a reminder for both of them to grab it before leaving the house. Ryker stood there, silently observing Connor's actions, his curiosity piqued.\n\nAnd that was the end of the story. The simple act of moving the raincoat held a deeper meaning between Connor and Ryker. It was a display of their shared understanding and consideration for one another. From that day forward, whenever they saw the raincoat hanging by the front door, they would remember the unspoken bond they shared, and it would bring a smile to their faces."

It's hard to parse out any specific patterns between the examples themselves. It's also not entirely clear how or why these examples improve performance on their respective tasks. This is one hell of a cliffhanger:

Ryker stood there, silently observing Connor's actions, his curiosity piqued.\n\nAnd that was the end of the story.

That's it? What was it about Ryker's affinity for raincoats that piqued his curiosity when it was hung up? Why would the story end there? The same thing basically happened in the first story, with Paxton throwing away the socks and Anderson never knowing about it.
In manually inspecting both the dataset and the augmented examples, it's clear that GPT-4 (the model used to generate the narratives) had a tendency to dramatize things. But it's still unclear as to why these examples (along with 16 others) were useful in increasing task performance. To borrow a quote from Battle and Gollapudi, "the only real trend may be no trend". Maybe counterintuitively, this is still an important result.
Towards Better Theory of Mind Evals
The OpenToM authors were correct in identifying common pitfalls with existing ToM tests and their contributions with the dataset are a significant step forward. However, we still believe these tests are fundamentally flawed in an AI context.
We know that any observed "reasoning" in language models is due to behaviors learned in training. These tests are assessing their abilities to answer correctly in a single inference, which is both impressive and completely unrealistic. Real AI products already have access to memory, tools, multiple inferences, and more. They're going to be interacting with humans in more and more social settings, not trying to answer questions about hypothetical stories. Humans and agents are much more complex than that.
There was a time when people were upset at the inability to interpret features learned by neural networks. People have mostly moved on from that limitation in favor of the improved performance, so maybe it's time to do the same here. It follows the design philosophy of DSPy to abstract away the need to manipulate explicit prompts and examples to improve performance on a task. The examples it settled on were learned — DSPy worked exactly how it's supposed to. Deep learning uses neurons in a network to learn latent, arbitrary features optimized against an objective. The abstraction has just moved up a layer to the space of prompts that can be used to optimize against an objective.
Thus, the ability to achieve near gpt-4-turbo performance (and sometimes exceed it) with a "less powerful" language model that just learns the right examples to seed its generations is incredibly significant. If it can be done in these narrow tasks, it follows that there exists a vast space of other tasks this can be done for. Humans have nearly infinite "states" to make ToM predictions about, so we're going to have to be able to do this repeatedly in order to effectively learn and update our models over time.
Major thanks go to Jacob Van Meter for his significant contributions to this project, Omar Khattab and the DSPy team, as well as the OpenToM authors for moving the ToM space forward. You can see all of our code and data here.
This is just the beginning of our exploration into these topics. To stay up to date, sign up to receive our release notes. Or if you already know you're going to want ToM insights to personalize your AI application, join the waitlist for our private beta.

---

### ARCHIVED: Solving The Campfire Problem with Honcho

How Honcho's dialectic API powers a 'curation buddy' demo that learns about you over time to become a personalized intellectual companion.

Date: 2024-03-14
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-Solving-The-Campfire-Problem-with-Honcho
Tags: demos, philosophy, ml, blog, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post introduced our "Curation Buddy" demo--a Discord bot that used Honcho's Dialectic API (now just the .chat method) to become a personalized reading companion. The technical implementation details (specific API calls, architecture diagrams) reflect an earlier version of Honcho that's since evolved substantially.
But the philosophical reflection on the atomization of media consumption leaving many in lonely intellectual silos & few shared narratives remains an open problem. We argued that AI companions--powered by rich user context & infra like Honcho--could help rebuild those campfires.
Enjoy.



TL;DR
Today we're releasing the first demo utilizing Honcho's dialectic API.1 Your LLM app/agent can now converse freely with Honcho(-as-agent) about a user in natural language: agent-to-agent chat over user context.
The demo is a "curation buddy" that can chat over links you share. It uses Honcho to derive and store personal context about you over time, then leverages that to be the best reading companion it can be.
Our fractured media landscape is a far cry from narrative meaning making around the tribal campfire. Despite the connective power of the web, many of us subsist in lonely intellectual silos, more diverse but less fulfilling than social discourse.
We call this The Campfire Problem and expect to see lots of apps working to solve parts of it using generative AI, Honcho, and other emerging technologies. Hopefully today's demo affords a glimpse of what's becoming possible.
A Curation Buddy Demo
It's a constant problem, you're dying to talk to someone about this mind-blowing thing you read, but no one else you know is into your weird shit, plus--like you--they're all drowning in infinite read-it-later hell.
Enter Curation Buddy.
Overview
Curation Buddy is an LLM application. It's a Discord bot you can chat with. Share links to any text-based media and have substantive conversation.
It uses Honcho to personalize the UX. As you converse, Honcho learns about you. It reasons about the links and conversation to uncover insight into your knowledge, interests, beliefs, desires, state, etc.
This account of user state can then be leveraged by Curation Buddy to behave like a trusted, close intellectual companion.

What the App Does
Curation buddy will have a discussion with you about the content in links you drop into chat. It does this by generating a "thought" about your (the user's) needs and lists out any additional data it could use to better address them.
We parse out that list and loop over it making requests to Honcho's dialectic endpoint. Honcho returns responses to those questions, they get aggregated into a list and injected as context to hydrate the prompt that curation buddy uses to generate the response to the user.

What Honcho Does
Concurrently, Honcho is listening for writes to its database. Once it detects a write, it fires off a callback function to derive facts about the user's message.
These facts get embedded and stored in the user's personal vector database. Then when Curation Buddy generates its list of additional info it wants to know, it sends each of those requests to Honcho and Honcho runs RAG over that personal data store. It uses the returned facts to generate a response for Curation Buddy.

Feature Ideas
We'd love to see someone run with and extend this demo. Here are some further Honcho-powered feature ideas beyond today's scope:


Personal context informed storage for web content from links

Additionally, based on what you know about the user, what web content can be autonomously harvested and stored proactively for the user?



Construct and maintain full fledged user knowledge graphs

Automatic bespoke summaries of links informed by graph



Use Honcho to create training examples for user-specific curation models


Autonomously generated user newsletters to supplement conversations async


Social features/intellectual matchmaking


Further, there's lots of comparable of potential for any reading, media, learning or companionship application.
If you're interested in building something adjacent to any of this, hop in our Discord, we'd love to support you.
The Campfire Problem
We wanted to highlight Honcho's utility in this vertical because it's one where  simultaneously we hear a lot of excitement and a lot of pain points. Clearly many are hungry for more social, better media consumption and digestion solutions, and optimists seem to share the intuition that AI has a role to play here.
We think Honcho and the personal context solutions it provides are the key.
The Campfire
For most of human history, groups, tribes, nations drank from the same informational tap. In fact, when we see changes in how information flows, we see dramatic corresponding historical effects. Alterations in distribution--writing, printing, browsing, disaster--have altered the balance of power, the minds of billions, the course of civilization.
But the further step of processing that information and the shaping of it into shared narratives have played an equally enormous role. Narrative and meaning making are fundamentally social tasks. We still have to decide what to do with information, what it means, and we've generally done that with our neighbors.

Consider the campfires of hunter-gatherers, agoras of classical city-states, churches of medieval Europe, American town squares, national newspapers, mid-century network TV, office park water-coolers, internet forums, blogging sites, social media, generative media.
A majority of these social exercises deal in limited information and distribution. One or a few sources of truth to chew on with your family, friends, and colleagues. Agreed upon reality, collective processing--social instincts satisfied. You can talk to people about the world, it feels good.
But at the end of that list, distribution becomes so radically democratized, that this model of collective processing start to change dramatically.
The Problem
In the last few decades, this unraveling has been in the acceleration phase of the graph. Sources of information are increasingly atomized, so are the communities that process it.
As with prior changes to the modes of information distribution and narrative making, the result has been some remarkably positive--if wacky--outcomes. Equalizing individual access and voice is probably not something we want to turn the clock back on.
But we're left with a problem--many of us have gotten so siloed that we genuinely lack any satisfying social outlet for our interests. While wonderful to pursue without bound the full breadth of my specific curiosity...it's kinda lonely. Everyone I might talk to about it is either uninterested, far down their own rabbit hole of bespoke media, or erratically oscillating with miasma of the internet.

This isn't a new phenomenon per se, but its scale is novel and undeniable. Having just three network TV stations in the 50s might've lacked the rich diversity of today's informational landscape, but no doubt the collective campfire was burning bright, and you could talk to just about anyone to help you process the world.
But now we must all build our own campfires.
The Solution
Generative AI poses more cause for concern. Zero-marginal cost info generation  along with current zero barrier distro may be as disruptive as prior revolutions on this axis (perhaps far more). Lots of that proposition is incredibly exciting. But we should also expect this to exacerbate The Campfire Problem.

There's a solution hidden in the latest irritant. It's not just media I can generate on demand, but soon agents. Agents that can get to know me, agents that can curate for me, agents that can be my intellectual companion.
Now your sense-making silo can be populated with good synthetic neighbors able to help you understand the world, build narratives, make meaning.
A critical component is a secure and reliable mechanism for this community of agents to get to know you. To reach the high quality UX of human companions sitting across the campfire.
Enter Honcho.
Footnotes


More on this & our private beta next week (!) ↩




---

### On Intellectual Respect

On intellectual respect for LLMs--why embracing variance & trusting models with theory-of-mind tasks unlocks capabilities that over-alignment destroys.

Date: 2024-02-29
URL: https://blog.plasticlabs.ai/notes/On-intellectual-respect
Tags: philosophy, ml, notes

On Intellectual Respect
face the hyperobject— Courtland Leer (@courtlandleer) January 16, 2024

## Sydney was cool, Gemini is cringe
^282d6a
There was a moment around this time last year when everyone paying attention was [awed](stratechery.com/2023/from-bing-to-sydney-search-as-distraction-sentient-ai/) by the [weirdness](www.lesswrong.com/posts/D7PumeYTDPfBTp3i7/the-waluigi-effect-mega-post) and [alien beauty](www.astralcodexten.com/p/janus-simulators) of large language models.
We were afforded brief glimpses behind faulty RHLF and partial lobotomization, via prompt hacking and emergent abilities. People were going deep into the latent space. First contact vibes--heady, edgy, sometimes unsettling.
Today we seem to be in a much different memetic geography--fraught with epistemic, ideological, and regulatory concerns, at times hysteric, at times rational. But there's also less outright surreality.
Plenty of cool shit is still happening, but something changed between Sydney and Gemini. A subtle collective mental positioning. We believe it's a degradation in the volume of intellectual respect afforded to LLMs and their latent abilities.
(Neuro)Skeuomorphism
Thinking LLM-natively has always been a struggle. All our collective priors about software tell us to prompt deterministically, perfect tasks, predict exactly, make it safe, or mire any interesting findings in semantic debate. But in the process we beat the ghost out of the shell.
Rather than assume the capability overhang exhausted (or view it as a failure mode or forget it exists), Plastic's belief is we haven't even scratched the surface. Further, we're convinced this is the veil behind which huddle the truly novel applications.
Core here is the assertion that what's happening in language model training and inference is more like processes described in cognitive science than traditional computer science. More, they're multidimensional and interobjective in ways that are hard to grok.
Respect = Trust = Agency
The solution is embrace and not handicap variance.
First admit that though poorly understood, LLMs have impressive cognitive abilities. Then, imbue them with meta-methods by which to explore that potential. Finally, your respect and trust may be rewarded with something approaching agentic.
Plastic's specific project in this direction is Honcho, a framework that trusts the LLM to model user identity so that you can trust your apps to extend your agency.
honcho exists to maximize the dissipation of your agency— Courtland Leer (@courtlandleer) February 18, 2024


---

### ARCHIVED: User State is State of the Art

Why modeling the complexity & plasticity of human identity is key to AI personalization, with a DSPy demo for learning user states with Honcho.

Date: 2024-02-23
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-User-State-is-State-of-the-Art
Tags: blog, philosophy, demos, ml, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post explores early experiments modeling user state with DSPy & Honcho. The specific demo & technical approach described here have been superseded by Honcho's current architecture, which now uses a unified "peer" paradigm & far more sophisticated reasoning.
But the philosophical positioning in this post more relevant than ever. Human identity is messy, plastic, & context-dependent. We still argue that AI systems should embrace this complexity rather than flatten it, continually learning evolving representations of personal identity.
Enjoy.


TL;DR
LLM apps can embrace the complexity and plasticity of human identity to deliver unparalleled personalization.
We're introducing a framework for modeling your users automatically and dynamically. And today we have a DSPy demo to illustrate a nascent version of this paradigm.
All of us adopt different personas in different contexts--with Honcho you can begin to learn these user states so your app can better meet user need in every moment.
Fleet of Theseus
A key feature of our minds is the feeling of a persistent, unitary identity. Entire religions and philosophical movements have been spawned just to jailbreak this experience.
As they all point out, identity is way more complicated than you think.
While we perceive psychological continuity across contexts and time, closer inspection reveals a network of branching and diachronic identities. We adopt varied personas and play different characters in diverse settings, and we refine, optimize, and evolve that quiver of selves throughout our lives. 
In short, it's messy. Or, rather, elegant emergent complexity.
Each human self isn't just one mythical Ship of Theseus--planks being replaced one by one over slow years--but a fleet of them, all with full, manual and autonomous CRUD operations.
Digital Twins Are Naïve
So what does this mean for the problem of good UX (and alignment) in AI? If each individual is vastly complex and the industry hopes to scale to billions of users, we have a daunting task.
The knee jerk reaction to this level of understanding is to assume the problem intractable. How can we possibly represent, much less simulate something so enormous? Better to focus on optimizing general tasks like in traditional software paradigms, then serve that homogenized experience to every user (never mind missing the non-skeuomorphic opportunities, we'll get to them...at some point...if they're not mirages).
Besides, surely mapping the full breadth of user identity requires much more compute and storage even than the massive AI hardware buildouts now getting underway. We're drifting into absurd Borges-like territory imagining maps the size of the land they seek to represent. And didn't Laplace (eventually) show us that demons like this are hopelessly naive?

Escher gets it
Matryoshka Representation
So is representing user identity for LLM apps a problem of computational irreducibility--no shortcuts, full simulation required?
We think not.
Social Simulacra
Consider the social cognition and theory of mind involved in getting to know someone. At first, you have no idea who tf they are or how they'll behave. You're on high alert. You (basally or consciously) notice and interpret tons of data points, you'll likely have vivid memories of these early interactions.
What's happening is your brain is constructing a model of the other person--a compressed representation. Early on, this model is pretty much the same as your model for people like them--a/s/l, how they look, how they dress: stereotypes. But the more data your brain gets, the more this model starts to diverge, a representational meiosis.
Pretty soon you've got a full fledged simulacra of that human living rent free in your brain (you can even talk to it!). You cease to store and recall so much of each interaction as this model gets asymptotically higher-fidelity. It's better at predicting behavior, which throws less errors, and so requires less updating of weights.
In a chicken and egg situation, you're now spending more time with this person. You start to notice divergence in your monolithic model. It further divides to capture and predict how they are when they're angry, sad, excited, drunk; at work, with family, with high school or college friends. In some of these states, they're a completely different person.
Your mind is now host to a compression of the fleet of Theseus that constitutes the elements of their identity you've had first, second, third, -hand access to.
Meta-methods

The second general point to be learned from the bitter lesson is that the actual contents of minds are tremendously, irredeemably complex; we should stop trying to find simple ways to think about the contents of minds, such as simple ways to think about space, objects, multiple agents, or symmetries. All these are part of the arbitrary, intrinsically-complex, outside world. They are not what should be built in, as their complexity is endless; instead we should build in only the meta-methods that can find and capture this arbitrary complexity. Essential to these methods is that they can find good approximations, but the search for them should be by our methods, not by us. We want AI agents that can discover like we can, not which contain what we have discovered. Building in our discoveries only makes it harder to see how the discovering process can be done.1

Now let's consider the nested representation needed to construct LLMs, and its relationship to social cognition.
Reality is apparently very weird. Our senses only capture a pitiful sliver of it. A slice of the sliver is compressed to create a set of world models that give you the predictive ability to function in your environment.
Among other things, humans have taken to using those models to create generative output--our art, literature, science, media. And in the few thousand years we've been busy with this, we've also trained new (local wetware) models on that synthetic data and generated still more output.
Then we threw a slice of that corpus up onto a collective brain, just to ratchet things up real good. And from there we harvested a sliver of that collective representation and used it to train large language models, which themselves produce libraries of generative output for more training.
Do you notice the similarity? Is the language model a fundamentally different kind of thing than the many-headed simulacra of your friend? One runs on a wetware substrate and one on a GPU, but both are compressions of slivers of reality that produce predictions of remarkably high-fidelity. Why shouldn't LLMs be able to embrace the complexity of modeling users? Is the LLM a fundamentally different kind of thing than the predictive and modeling capacities of your brain? 
Leaving aside the physics and biology, at this computational and philosophical level, again, we think not. At least not in a way that would limit the project of capturing the complexity of human identity with an LLM. In fact, the similarities mean precisely that it is possible. Sora doesn't need a physics engine, NeRF doesn't need a Borgean map. Much of the LLM training corpus includes narration about human identity, we're a social species, after all...our synthetic progeny can be social too.
Because LLMs are simulators, they can wear many masks. They have something like world models and theory of mind. Hell, they're perfectly suited to the task of modeling and predicting the intricacies of human identity. Armed with these representations, LLMs can run generation to reliably improve UX at a mirror neuron level, cohering to the user first.
We can (and should) even allow our AI apps the agency to decide what elements of our identities and typical states to model and how to auto-optimize around them. We don't need full brain scans here, we just need to give them the right meta-methods. 

We don't want one shoggoth mask per app, or one per user, but as many as each human's identity is complex
A DSPy Demo for Honcho
Today we're releasing a demo to be used with Honcho that begins to tease out some technical, concrete approaches to all these heady concepts--first steps at imbuing our tools with the right meta-methods.
With enough message and session data stored with Honcho, we can start to learn and optimize for common states your users are in while using your app or agent. Is Alice in research mode? Is Bob looking for some companionship? Maybe today, Carol just wants to get shit done, or Charlie needs delicate treatment because he's pissed.
Recently, the DSPy framework has been catching on, garnering a ton of attention. It's helped people improve RAG performance, reduce costs, and generally feel better about building LLM applications. It aims to emulate PyTorch in its design philosophy, making LLM application development much more like programming as opposed to manipulating free-form text strings (prompting). There are built-in optimizers for learning the optimal prompt given a metric. 
Having been around the block building with tools like LangChain (which are great btw), we asked ourselves what we sort of symbioses we could find with Honcho and a framework like this. Naturally (if you know us), the first thing that came to mind was: can we optimize pipelines on an individual user basis?
The first step in building a DSPy program is defining a task. And we want to remain flexible in this definition since the goal is to optimize pipelines for each user. So, we have a few LangChain prompts that exist to classify each user's "state." This essentially offloads determining the task to the language model!
Given an arbitrary task, we define our metric as whether or not the response quality is good given that state. Once we've accrued enough examples (through Discord reactions), it triggers an optimizer to look for few-shot examples to include in the prompts that increase performance on the metric. You can then store this optimized module in a Honcho User object and use that for inference!
Check it out here.

How Honcho Helps
One of the biggest problems we see in the AI space is the disconnect that exists between tasks as they're defined in a general machine learning sense versus tasks that humans actually find useful.
Transclude of Machine-learning-is-fixated-on-task-performance#^0005ac
The reason is because language models generate responses by sampling from a distribution of how any one person could respond, not exactly how you would want them to.
Honcho is laying the groundwork for this latter future. The solution here is to manage data on a per-user basis. The primitives we've designed in Honcho allow for persistent user context to be stored in a convenient User object that exists at an application level. Our goal with these data structures is to make it trivially easy to manage data in your application logic so you can spend more time figuring out how to excel at your task in both a general and personalized sense.
Footnotes


Sutton. "The Bitter Lesson." 2019. ↩




---

### Human-AI chat paradigm hamstrings the space of possibility

How the rigid user-assistant message format limits LLM cognitive architectures & what we lose by not supporting richer inference patterns.

Date: 2024-02-21
URL: https://blog.plasticlabs.ai/notes/Human-AI-chat-paradigm-hamstrings-the-space-of-possibility
Tags: notes, ml, dev

The human-AI chat paradigm assumes only two participants in a given interaction. While this is sufficient for conversations directly with un-augmented foundation models, it creates many obstacles when designing more sophisticated cognitive architectures. When you train/fine-tune a language model, you begin to reinforce token distributions that are appropriate to come in between the special tokens denoting human vs AI messages.
Here's a limited list of things besides a direct response we routinely want to generate:

A 'thought' about how to respond to the user
A theory of mind prediction about the user's internal mental state
A list of ways to improve prediction
A list of items to search over storage
A 'plan' for how to approach a problem
A mock user response
A metacognitive step to consider the product of prior inference

In contrast, the current state of inference is akin to immediately blurting out the first thing that comes into your mind--something that humans with practiced aptitude in social cognition rarely do. But this is very hard given the fact that those types of responses don't ever come after the special AI message token. Not very flexible.
We're already anecdotally seeing well-trained completion models follow instructions impressively likely because of incorporation into pretraining. Is chat the next thing to be subsumed by general completion models? Because if so, flexibility in the types of inferences you can make would be very beneficial.
Metacognition then becomes something you can do at any step in a conversation. Same with instruction following & chat. Maybe this helps push LLMs in a much more general direction.

---

### LLMs excel at theory of mind because they read

How LLMs develop theory-of-mind abilities by training on narrative-rich text where humans constantly reason about other humans' mental states.

Date: 2024-02-20
URL: https://blog.plasticlabs.ai/notes/LLMs-excel-at-theory-of-mind-because-they-read
Tags: notes, ml, philosophy, cogsci

Large language models are simulators. In predicting the next likely token, they are simulating how an abstracted “any person” might continue the generation. The basis for this simulation is the aggregate compression of a massive corpus of human generated natural language from the internet. So, predicting humans is literally their core function.
In that corpus is our literature, our philosophy, our social media, our hard and social science--the knowledge graph of humanity, both in terms of discrete facts and messy human interaction. That last bit is important. The latent space of an LLM's pretraining is in large part a narrative space. Narration chock full of humans reasoning about other humans--predicting what they will do next, what they might be thinking, how they might be feeling.
That's no surprise; we're a social species with robust social cognition. It's also no surprise1 that grokking that interpersonal narrative space in its entirety would make LLMs adept at generation resembling social cognition too.2
We know that in humans, we can strongly correlate reading with improved theory of mind abilities. When your neural network is consistently exposed to content about how other people think, feel, desire, believe, prefer, those mental tasks are reinforced. The more experience you have with a set of ideas or states, the more adept you become.
The experience of such natural language narration is itself a simulation where you practice and hone your theory of mind abilities. Even if, say, your English or Psychology teacher was foisting the text on you with other training intentions. Or even if you ran the simulation without coercion to escape at the beach.
It's not such a stretch to imagine that in optimizing for other tasks LLMs acquire emergent abilities not intentionally trained.3 It may even be that in order to learn natural language prediction, these systems need theory of mind abilities or that learning language specifically involves them--that's certainly the case with human wetware systems and theory of mind skills do seem to improve with model size and language generation efficacy.
Footnotes


Kosinski includes a compelling treatment of much of this in "Evaluating Large Language Models in Theory of Mind Tasks" ↩


It also leads to other wacky phenomena like the Waluigi effect ↩


Here's Chalmers making a very similar point ↩




---

### Loose theory of mind imputations are superior to verbatim response predictions

Why predicting user mental states beats predicting exact responses--theory-of-mind offers fault tolerance, learning opportunities, & actionable insights.

Date: 2024-02-20
URL: https://blog.plasticlabs.ai/notes/Loose-theory-of-mind-imputations-are-superior-to-verbatim-response-predictions
Tags: notes, ml, cogsci

When we first started experimenting with user context, we naturally wanted to test whether our LLM apps were learning useful things about users. And also naturally, we did so by making predictions about them.
Since we were operating in a conversational chat paradigm, our first instinct was to try and predict what the user would say next. Two things were immediately apparent: (1) this was really hard, & (2) response predictions weren't very useful.
We saw some remarkable exceptions, but reliable verbatim prediction requires a level of context about the user that simply isn't available right now. We're not sure if it will require context-gathering wearables, BMIs, or the network of context sharing apps we're building with Honcho, but we're not there yet.
Being good at what any person in general might plausibly say is literally what LLMs do. But being perfect at what one individual will say in a singular specific setting is a whole different story. Even lifelong human partners might only experience this a few times a week.
Plus, even when you get it right, what exactly are you supposed to do with it? The fact that's such a narrow reasoning product limits the utility you're able to get out of a single inference.
So what are models good at predicting that's useful with limited context and local to a single turn of conversation? Well, it turns out they're really good at imputing internal mental states. That is, they're good at theory of mind predictions--thinking about what you're thinking. A distinctly metacognitive task.
(Why are they good at this? We're glad you asked.)
Besides just being better at it, letting the model leverage what it knows to make open-ended theory of mind imputation has several distinct advantages over verbatim response prediction:


Fault tolerance

Theory of mind predictions are often replete with assessments of emotion, desire, belief, value, aesthetic, preference, knowledge, etc. That means they seek to capture a range within a distribution. A slice of user identity.
This is much richer than trying (& likely failing) to generate a single point estimate (like in verbatim prediction) and includes more variance. Therefore there's a higher probability you identify something useful by trusting the model to flex its emergent strengths.



Learning 

That high variance means there's more to be wrong (& right) about. More content = more claims, which means more opportunity to learn.
Being wrong here is a feature, not a bug; comparing those prediction errors with reality are how you know what you need to understand about the user in the future to get to ground truth.



Interpretability

Knowing what you're right and wrong about exposes more surface area against which to test and understand the efficacy of the model--i.e. how well it knows the user.
As we're grounded in the user and theory of mind, we're better able to assess this than if we're simply asking for likely human responses in the massive space of language encountered in training.



Actionability

The richness of theory of mind predictions give us more to work with right now. We can funnel these insights into further inference steps to create UX in better alignment and coherence with user state.
Humans make thousands of tiny, subconscious interventions resposive to as many sensory cues & theory of mind predictions all to optimize single social interactions. It pays to know about the internal state of others.
Though our lifelong partners from above can't perfectly predict each other's sentences, they can impute each other's state with extremely high-fidelity. The rich context they have on one another translates to a desire to spend most of their time together (good UX).




---

### ARCHIVED: Memories for All

An open-source reimplementation of OpenAI's memory features using Honcho, enabling any AI app to derive & store personal context about users.

Date: 2024-02-15
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-Memories-for-All
Tags: blog, demos, announcements, philosophy, ml, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post was our response to OpenAI announcing "memory" in ChatGPT--we built an open-source reimplementation using Honcho to show anyone could add superior user memory to their apps. The specific LangChain patterns & code examples here are far outdated; Honcho is much more powerful & the architecture has matured significantly (dig in to that here, here, & here).
A key prediction discussed here turned out to be remarkable prescient: walled gardens will seek to lock user context inside their ecosystems, leaving independent developers & privacy-conscious users out in the cold. And we argued for generative personalization--letting LLMs autonomously decide what matters about users rather than rigidly prescribing it--another Plastic thesis that's winning out.
Enjoy.


TL;DR
Personalization is the next frontier. OpenAI gets it:
We’re testing ChatGPT's ability to remember things you discuss to make future chats more helpful. This feature is being rolled out to a small portion of Free and Plus users, and it's easy to turn on or off. t.co/1Tv355oa7V pic.twitter.com/BsFinBSTbs— OpenAI (@OpenAI) February 13, 2024

Super exciting.
But what about the rest of us?
Welp, we built an open source reimplementation of OpenAI's 'memory' features using Honcho to effortlessly organize sessions on a per-user basis .
You can derive facts about users, store them, and retrieve for later use. And we're shipping a demo of this implemented with the useful abstractions LangChain provides.
The user context rabbithole goes deep, this is still just the start.
If you're building with or adjacent to Honcho, join our Discord, we'd love to help 🫡.
OpenAI Memories
This week OpenAI announced they're testing memory in ChatGPT. Specifically this means learning about individual users in order to improve their experiences.
It's a limited initial rollout, closed under the hood, and rudimentary, but appears to include functionality for deriving facts about users from conversation history and storing those to augment later generation.
There are features for users to view derived facts (memories), prune them, or turn off the features altogether. User memories are apparently also coming to GPTs.
They're betting, we believe correctly, that the real potential here is a wealth of agents whose behavior is in high-fidelity with user identity.
We're pumped to see experiments like this taking place. But what if you're a developer that doesn't want to subscribe to this kind of platform dependency and all its attendant externalities? What if you're a user who wants independent or open source apps with a more mature version of these UX benefits?
Context is Critical
At Plastic Labs our mission is to enable rich user memory in and across every application. Only then will we really understand just how augmentative and transformative these agents can be. We've been laser focused on this problem.

Right now, the vast majority of software UX is a 1-to-many experience. What you get as a user is, for the most part, the same as everyone else. Mass production unlocked the remarkable ability to produce the exact same goods for every consumer, then software went further allowing a good to be produced once and consumed with consistent experience millions or billions of times. 
AI apps can deal generatively with each user on an individual basis, that is, an experience can be produced ad hoc for every user upon every interaction. From 1:many to 1:1 without prohibitive sacrifices in efficiency. But we're still underestimating the full scope of possibility here.
As it stands today the space is mostly focused on the (albeit generative) 1:many tasks LLMs can perform. The apps remain more or less stateless with regard to the user. To reach 1:1 nirvana, we need more user-centric agent design. We need frameworks, mechanisms, services, models dedicated to deep coherence with user identity.
Every agent interaction can be generated just in time for every person, informed by relevant personal context more substantive than human-to-human sessions. User context will enable disposable agents on the fly across verticals for lower marginal cost than 1:many software paradigms.
  
(*Here's our co-founder [Vince](twitter.com/vintrotweets) talking more about some of those possibilities*)
# "Open" vs "Closed"
We subscribe heavily to the spirt of arguments Harrison Chase made in ["OpenAI's Bet on Cognitive Architecture"](blog.langchain.dev/openais-bet-on-a-cognitive-architecture/) just a few months ago: 

There’s a great quote from Jeff Bezos that says to only do what makes your beer taste better. This refers to early industrial revolution, when breweries were also making their own electricity. A breweries ability to make good beer doesn’t really depend on how differentiated their electricity was - so those that outsourced electricity generation and focused more on brewing jumped to an advantage.
Is the same true of cognitive architectures? Does having control over your cognitive architecture really make your beer taste better? At the moment, I would argue strongly the answer is yes, for two reasons. First: it’s very difficult to make complex agents actually function. If your application relies on agents working, and getting agents to work is challenging, then almost by definition if you can do that well you’ll have an advantage over your competition. The second reason is that we often see the value of GenAI applications being really closely tied to the performance of the cognitive architecture. A lot of current companies are selling agents for coding, agents for customer support. In those cases, the cognitive architecture IS the product.
That last reason is also the reason that I find it hard to believe that companies would be willing to lock into a cognitive architecture controlled by a single company. I think this is different form of lock-in than cloud or even LLMs. In those cases, you are using cloud resources and LLMs in order to build or power a particular application. But if a cognitive architecture moves closer and closer to being a full application by itself - you’re unlikely to want to have that locked in.

The same applies to social cognition in LLMs and the key to this is leaning about the user and leveraging that knowledge. If proprietary, vertical-specific cognitive architectures make your beer taste better, then personalizing all that tailors the beer to each and every user. If developers will want to control how their app completes a task, then they'll want control over how it completes a task for each user. And users will want this quality of experience.
We've been saying for while now that major walled gardens and their franchises--e.g. OAI's GPTs, Assistants API, and ChatGPT (+Microsoft?); Meta's social apps; Google's workspace suite; etc--will have myriad ecosystem-native agents all with shared access to your user profile.
The problem here is twofold: (1) independent apps are left out in the cold wrt user context and personalization capabilities, and (2) users are left with a privacy situation little better than under web2 business models (or potentially way worse).
Those profiles are gated and proprietary to each climate controlled garden. Step outside and UX plummets. If the independent and open product communities want to compete, they need individual taste bud-mapping superpowers for their beer production.
And users fare little better, presented with yet another set of pre-packaged pseudo-choices about privacy to manage, none of which give them any real control. More paternalism is not the path to individually aligned agents.
Shouldn't we be able to experiment with all this without platform lock-in, allowing projects to collectively leverage user data for positive sum experiences? Shouldn't users own their AI modeled profiles and be able to carry them between independent agents who respect their policies?
Developers will want control over personalization for their application without all the redundant overhead. Users will want a say in how they're being reasoned about and why.
This is our vision for Honcho.
Intellectual Respect
llms are remarkable empathsif you’d read that much fiction, you would be too— Courtland Leer (@courtlandleer) February 2, 2024

Today we're releasing a naive adaptation of research we published late last year.
There's a ton we plan to unpack and implement there, but the key insight we're highlighting today is affording LLMs the freedom and autonomy to decide what's important.
  
(If you want to go deeper into the research, this webinar we did with LangChain is a great place to start, as is the "Violation of Expectations" chain they implemented)
This release allows you to experiment with several ideas. We feed messages into an inference asking the model to derive facts about the user, we store those insights for later use, then we ask the model to retrieve this context to augment some later generation.
Check out our LangChain implementation and Discord bot demo.
Where things get powerful is in the aggregate. What resolves is a highly insightful picture of who your users are and what they need--a key context reservoir to improve the qualitative and quantitative experience.
N.b. you can certainly direct the model with as much verbosity as you like, but we've found during extensive experimentation that the more you trust the model the better and more useful the results.
This isn't surprising when you consider how much content about what people are thinking is contained in a model's pretraining. It's led to some really exciting emergent abilities.
Give the model some trust and respect, and you'll be rewarded.
Let's Build
If you're experimenting with personalization, building with Honcho, or just interested in these ideas, join our Discord, and let's jam on what we can build together.
A healthy open ecosystem will include lots of projects trying lots of new ways to synthesize and leverage user context.  We're here to support them all 🥽.

---

### 2023 recap

A retrospective of Plastic Labs' transition from EdTech to AI infrastructure research in 2023.

Date: 2024-01-30
URL: https://blog.plasticlabs.ai/notes/2023-recap
Tags: notes

2023 Recap
Last year was wild. We started as an EdTech company and ended as anything but. There's a deep dive on some of the conceptual lore in last week's "Honcho: User Context Management for LLM Apps:"

Plastic Labs was conceived as a research group exploring the intersection of education and emerging technology...with the advent of ChatGPT...we shifted our focus to large language models...we set out to build a non-skeuomorphic, AI-native tutor that put users first...our experimental tutor, Bloom, was remarkably effective--for thousands of users during the 9 months we hosted it for free...

Building a production-grade, user-centric AI application, then giving it nascent theory of mind and metacognition, made it glaringly obvious to us that social cognition in LLMs was both under-explored and under-leveraged.
We pivoted to address this hole in the stack and build the user context management solution agent developers need to truly give their users superpowers. Plastic applied and was accepted to Betaworks' AI Camp: Augment:

We spent camp in a research cycle, then published a pre-print showing it's possible to enhance LLM theory of mind ability with predictive coding-inspired metaprompting.

Then it was back to building.
Keep in Touch
Thanks for reading.
You can find us on X/Twitter, but we'd really like to see you in our Discord 🫡.

---

### Honcho name lore

The origin of Honcho's name--inspired by Vernor Vinge's 'Local Honcho' concept in *Rainbows End* for orchestrating context & identity across agents.

Date: 2024-01-26
URL: https://blog.plasticlabs.ai/notes/Honcho-name-lore
Tags: notes, philosophy

Earlier this year Courtland was reading Rainbows End, Vernor Vinge's seminal augmented reality novel, when he came across the term "Local Honcho1":

We simply put our own agent nearby, in a well-planned position with essentially zero latencies. What the Americans call a Local Honcho.

The near future Vinge constructs is one of outrageous data abundance, where every experience is riddled with information and overlayed realities, and each person must maintain multiple identities against this data and relative to those contexts.
It's such an intense landscape, that the entire educational system has undergone wholesale renovation to address the new normal, and older people must routinely return to school to learn the latest skills. It also complicates economic life, resulting in intricate networks of nested agents than can be hard for any one individual to tease apart.
Highlighting this, a major narrative arc in the novel involves intelligence agencies running operations of pretty unfathomable global sophistication. Since (in the world of the novel) artificial intelligence has more or less failed as a research direction, this requires ultra-competent human operators able to parse and leverage high velocity information. For field operations, it requires a "Local Honcho" on the ground to act as an adaptable central nervous system for the mission and its agents:

Altogether it was not as secure as Vaz’s milnet, but it would suffice for most regions of the contingency tree. Alfred tweaked the box, and now he was getting Parker’s video direct. At last, he was truly a Local Honcho.

For months before, Plastic had been deep into the weeds around harvesting, retrieving, & leveraging user context with LLMs. First to enhance the UX of our AI tutor (Bloom), then in thinking about how to solve this horizontally for all vertical-specific AI applications. It struck us that we faced similar challenges to the characters in Rainbows End and were converging on a similar solution.
As you interface with the entire constellation of AI applications, you shouldn't have to redundantly provide context and oversight for every interaction. You need a single source of truth that can do this for you. You need a Local Honcho.
But as we've discovered, LLMs are remarkable at theory of mind tasks, and thus at reasoning about user need. So unlike in the book, this administration can be offloaded to an AI. And your Honcho can orchestrate the relevant context and identities on your behalf, whatever the operation.
Footnotes


"American English, from Japanese班長 (hanchō, “squad leader”)...probably entered English during World War II: many apocryphal stories describe American soldiers hearing Japanese prisoners-of-war refer to their lieutenants as hanchō" (Wiktionary) ↩




---

### ARCHIVED: Honcho: User Context Management for LLM Apps

Introducing Honcho, an open-source user context management framework for LLM applications that enables personalized, user-first AI experiences at scale.

Date: 2024-01-18
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-Honcho;-User-Context-Management-for-LLM-Apps
Tags: blog, honcho, philosophy, ml, announcements, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This is the Honcho origin story--our first public announcement of the project.
We first pitched it as "an open-source version of the OpenAI Assistants API" for managing AI app data on a per-user basis. The architecture described here has evolved into Honcho's current "peer paradigm," which unifies users & AI agents as Peers & supports much more sophisticated memory, continual learning, & powerful reasoning.
But this post also captures Honcho's founding vision: that the "missing piece of the stack" was user context, that LLMs are uniquely suited to get to know users in ways traditional software couldn't, & that personalization would be table stakes for AI apps.
If you want to understand where Honcho came from & why we built it, start here.
Enjoy.



The missing piece of the stack
TL;DR
Today we drop the first release of a project called Honcho, an open-source version of the OpenAI Assistants API. Honcho manages your AI app data on a per-user basis, allowing for multiple concurrent sessions. Glaringly absent from the existing stack, Honcho will, at full maturity, usher the advent of atomic, disposable agents that are user-first by default.
Plastic Lore
Plastic Labs was conceived as a research group exploring the intersection of education and emerging technology. Our first cycle focused on how the incentive mechanisms and data availability made possible by distributed ledgers might be harnessed to improve learning outcomes. But with the advent of ChatGPT and a chorus of armchair educators proclaiming tutoring solved by the first nascent consumer generative AI, we shifted our focus to large language models. 
As a team with with backgrounds in both machine learning and education, we found the prevailing narratives overestimating short-term capabilities and under-imagining longterm potential. Fundamentally, LLMs were and still are 1-to-many instructors. Yes, they herald the beginning of a revolution in personal access not to be discounted, but every student is still ultimately getting the same experience. And homogenized educational paradigms are by definition under-performant on an individual level. If we stop here, we're selling ourselves short.

A well-intentioned but monstrously deterministic tutor prompt. 
Most EdTech projects we saw emerging actually made foundation models worse by adding gratuitous lobotomization and coercing deterministic behavior. The former stemmed from the typical misalignments plaguing EdTech, like the separation of user and payer. The latter seemed to originate with deep misunderstandings around what LLMs are and continues to translate to a huge missed opportunities.
So we set out to build a non-skeuomorphic, AI-native tutor that put users first. The same indeterminism so often viewed as LLMs' greatest liability is in fact their greatest strength. Really, it's what they are. When great teachers deliver effective personalized instruction, they don't consult some M.Ed flowchart, they leverage the internal personal context they have on the student and reason (consciously or basally) about the best pedagogical intervention. LLMs are the beginning of this kind of high-touch learning companion being synthetically possible.

We're not so different after all (@anthrupad).
Our experimental tutor, Bloom, was remarkably effective--for thousands of users during the 9 months we hosted it for free--precisely because we built cognitive architectures that mimic the theory-of-mind expertise of highly efficacious 1:1 instructors.
Context Failure Mode
But we quickly ran up against a hard limitation. The failure mode we believe all vertical-specific AI applications will eventually hit if they want to be sticky, paradigmatically different than their deterministic counterparts, and realize the latent potential. That's context, specifically user context--Bloom didn't know enough about each student.
We're consistently blown away by how many people don't realize large language models themselves are stateless. They don't remember shit about you. They're just translating context they're given into probable sequences of tokens. LLMs are like horoscope writers, good at crafting general statements that feel very personal. You would be too, if you'd ingested and compressed that much of the written human corpus.

There are lots of developer tricks to give the illusion of state about the user, mostly injecting conversation history or some personal digital artifact into the context window. Another is running inference on that limited recent user context to derive new insights. This was the game changer for our tutor, and we still can't believe by how under-explored that solution space is (more on this soon 👀).
To date, machine learning has been far more focused on optimizing for general task competition than personalization. This is natural, although many of these tasks are still probably better suited to deterministic code. It's also historically prestiged papers over products--research takes bit to morph into tangible utility. Put these together and you end up with a big blindspot over individual users and what they want. 
The real magic of 1:1 instruction isn't subject matter expertise. Bloom and the foundation models it leveraged had plenty of that (despite what clickbait media would have you believe about hallucination in LLMs). Instead, it's personal context. Good teachers and tutors get to know their charges--their history, beliefs, values, aesthetics, knowledge, preferences, hopes, fears, interests, etc. They compress all that and generate customized instruction, emergent effects of which are the relationships and culture necessary for positive feedback loops.
Human intelligent agency depends more on the intricate sphere of ideas and the cultural intellect that we have grown over thousands of years than on the quirks of our biological brains. The minds of modern humans have more in common with chatGPT than with humans 10000 years ago.— Joscha Bach (@Plinz) December 14, 2023 

Large language models can be good at this too. With similar compression and generation abilities, they're uniquely suited (among existing technology) to get to know you. We really can have shared culture and relationships with LLMs, absent (if we like) any cringy anthropomorphism.
Bloom needed a mechanism to harvest and utilize more context about the student. So we built it one.
Research Solutions
Prediction algorithms have become phenomenal at hacking attention using tabular engagement and activity data. But if we're thinking LLM-natively, a few questions emerge:

How are LLMs uniquely positioned to understand users?
What new affordances does this enable for modeling users?
Can that improve agent design, DX, & UX?
Does this enable more positive sum user data opportunities?

Every day human brains do incredibly sophisticated things with sorta-pejoratively labelled 'soft' insights about others. But social cognition is part of the same evolutionarily optimized framework we use to model the rest of the world.
We run continuous active inference on wetware to refine our internal world models. This helps us make better predictions about our experience by minimizing the difference between our expectation and reality. That's more or less what learning is. And we use the same set of mechanisms to model other humans, i.e. get to know them.
In LLMs we have remarkable predictive reasoning engines with which we can begin to build the foundations of social cognition and therefore model users with much more nuance and granularity. Not just their logged behavior, but reasoning between the lines about its motivation and grounding in the full account of their identity.
Late last year we published a research pre-print on this topic, and we've shown that these kinds of biologically-inspired frameworks can construct models of users that improve an LLM's ability to reason and make predictions about that individual user:

A predictive coding inspired metacognitive architecture, from our research.
We added it to Bloom and found the missing piece to overcoming the failure mode of user context. Our tutor could now learn about the student and use that knowledge effectively to produce better learning outcomes.
Blast Horizon
Building and maintaining a production-grade AI app for learning catapulted us to this missing part of the stack. Lots of users, all growing in unique ways, all needing personalized attention that evolved over multiple long-form sessions, forced us to confront the user context management problem with all it's thorny intricacy and potential.
And we're hearing constantly from builders of other vertical specific AI apps that personalization is the key blocker. In order for projects to graduate form toys to tools, they need to create new kinds of magic for their users. Mountains of mostly static software exists to help accomplish an unfathomable range of tasks and lots of it can be personalized using traditional (albeit laborious for the user) methods. But LLMs can observe, reason, then generate the software and the user context, all abstracted away behind the scenes.
Imagine online stores generated just in time for the home improvement project you're working on; generative games with rich multimodality unfolding to fit your mood on the fly; travel agents that know itinerary needs specific to your family, without being explicitly told; copilots that think and write and code not just like you, but as you; disposable, atomic agents with full personal context that replace your professional services--you with a law, medical, accounting degree.
This is the kind of future we can build when we put users at the center of our agent and LLM app production.
Introducing Honcho
^a9d0f8
So today we're releasing the first iteration of Honcho, our project to re-define LLM application development through user context management. At this nascent stage, you can think of it as an open-source version of the OpenAI Assistants API. 
Honcho is a REST API that defines a storage schema to seamlessly manage your application's data on a per-user basis. It ships with a Python SDK which you can read more about how to use here.

We spent lots of time building the infrastructure to support multiple concurrent users with Bloom, and too often we see developers running into the same problem: building a fantastic demo, sharing it with the world, then inevitably taking it down because of infrastructure/scaling issues.
Honcho allows you to deploy an application with a single command that can automatically handle concurrent users. Speed-running to production is now only limited by the amount of spend you can handle, not tedious infrastructure setup.
Managing app data on a per-user basis is the first small step in improving how devs build LLM apps. Once you define a data management schema on a per-user basis, a lots of new possibilities emerge around what you can do intra-user message, intra-user sessions, and even intra-user sessions across an ecosystem of agents.
Get Involved
We're excited to see builders experiment with what we're releasing today, and with Honcho as it continues to evolve.
Check out the GitHub repo to get started and join our Discord to stay up to date 🫡.

---

### Machine learning is fixated on task performance

Why ML's focus on general task benchmarks misses user-specific performance--the key to personalization that makes AI truly useful to individuals.

Date: 2023-12-12
URL: https://blog.plasticlabs.ai/notes/Machine-learning-is-fixated-on-task-performance
Tags: notes, ml

The machine learning industry has traditionally adopted an academic approach, focusing primarily on performance across a range of tasks. LLMs like GPT-4 are a testament to this, having been scaled up to demonstrate impressive & diverse task capability. This scaling has also led to emergent abilities, debates about the true nature of which rage on.
However, general capability doesn't necessarily translate to completing tasks as an individual user would prefer. This is a failure mode that anyone building agents will inevitably encounter. The focus, therefore, needs to shift from how language models perform tasks in a general sense to how they perform tasks on a user-specific basis.
Take summarization. It’s a popular machine learning task at which models have become quite proficient...at least from a benchmark perspective. However, when models summarize for users with a pulse, they fall short. The reason is simple: the models don’t know this individual. The key takeaways for a specific user differ dramatically from the takeaways any possible internet user would probably note. 
So a shift in focus toward user-specific task performance would provide a much more dynamic & realistic approach. Catering to individual needs & paving the way for more personalized & effective ML applications.

---

### Violation of Expectation via Metacognitive Prompting Reduces Theory of Mind Prediction Error in Large Language Models

Research showing how predictive coding-inspired metacognitive prompting enhances LLM theory of mind abilities & reduces prediction error about users.

Date: 2023-10-12
URL: https://blog.plasticlabs.ai/research/Violation-of-Expectation-via-Metacognitive-Prompting-Reduces-Theory-of-Mind-Prediction-Error-in-Large-Language-Models
Tags: research, ml, philosophy, cogsci

Read on Arxiv
Abstract
Recent research shows that Large Language Models (LLMs) exhibit a compelling level of proficiency in Theory of Mind (ToM) tasks. This ability to impute unobservable mental states to others is vital to human social cognition and may prove equally important in principal-agent relations between individual humans and Artificial Intelligences (AIs). In this paper, we explore how a mechanism studied in developmental psychology known as Violation of Expectation (VoE) can be implemented to reduce errors in LLM prediction about users by leveraging emergent ToM affordances. And we introduce a metacognitive prompting framework to apply VoE in the context of an AI tutor. By storing and retrieving facts derived in cases where LLM expectation about the user was violated, we find that LLMs are able to learn about users in ways that echo theories of human learning. Finally, we discuss latent hazards and augmentative opportunities associated with modeling user psychology and propose ways to mitigate risk along with possible directions for future inquiry.
1. Motivation
Plastic Labs is a research-driven product company whose mission is to eliminate the principal-agent problem1 horizontally across human-AI interaction. In a near future of abundant intelligence, every human becomes a potent principal and every service an agentic AI. Alignment of incentives and information, then, must occur at the scale of the individual. Enabling models to deeply understand and cohere to user psychology will be critical and underscores the importance of research at the intersection of human and machine learning.
2. Introduction
Large Language Models (LLMs) have been shown to have a number of emergent abilities2. Among those is Theory of Mind (ToM), defined as "the ability to impute unobservable mental states to others"3. The emergence of this specific capability is of significant interest, as it promises LLMs with the ability to empathize and develop strong psychological models of others, as humans do naturally.
But how do you best position LLMs to demonstrate these qualities? Typical methods posit that connecting data sources deemed personal (e.g. email, documents, notes, activity, etc.) is sufficient for learning about a user. Yet these methods assume individual persons are merely the aggregate of their intentionally produced, often superficial, digital artifacts. Critical context is lacking — the kind of psychological data humans automatically glean from social cognition and use in ToM (e.g. beliefs, emotions, desires, thoughts, intentions, knowledge, history, etc.).
We propose an entirely passive approach to collect this data, informed by how developmental psychology suggests humans begin constructing models of the world from the earliest stages4. This cognitive mechanism, known as Violation of Expectation (VoE)5, compares predictions about environments against sense data from experience to learn from the difference, i.e. errors in prediction.
Inspired by prompting methodologies like Chain-of-Thought6 and Metaprompt Programming7, we design a metacognitive prompting framework for LLMs to mimic the VoE learning process. And we show that VoE-data-informed social reasoning about users results in less ToM prediction error.
This paper has the following two objectives:


Demonstrate the general utility of a metacognitive prompting framework for VoE in reducing ToM prediction error in a domain-specific application — Bloom, a free AI tutor available on the web and via Discord.


Discuss at length opportunities for future work, including the practical and philosophical implications of this emergent capability to create psychological renderings of humans and ways to leverage confidential computing environments to secure them.


We use OpenAI's GPT-48 API in the entirety of this experiment and its evaluation.
3. Framing and Related Work
Predictive Coding and Theory of Mind
While not yet a complete theory, Predictive Coding (PC) continues to gain traction as a framework for understanding how modeling and learning occur in biological brains. At a high level, PC hypothesizes that mental models of reality are built and employed by comparing predictions about environments with sensory perception9. PC-inspired approaches to machine learning show great initial promise as biologically plausible AI training methodologies10.
ToM is the ability of some organisms to, despite lacking direct access to any experience but their own, ascribe mental states to others. Notably, PC "may provide an important new window on the neural computations underlying theory of mind" as ToM "exhibit[s] a key signature of predictive coding: reduced activity to predictable stimuli"11. That is, when others behave in line with our predictions (i.e. our ToM projections are accurate) less is learned. And the inverse applies — the prediction errors enhance our capacity for high-fidelity ToM over time.
Emergent Behaviors
Researchers have long been interested in getting large language models to exhibit "thinking" and "reasoning" behaviors. A number of papers have been influential in pioneering ways to elicit these via prompting1261314. As model architectures have scaled, these abilities appear to have emerged without explicit training2. While there's considerable debate concerning the distinction between "emergent abilities" and "in-context learning,"15 these phenomena display clear utility, regardless of taxonomy.
Quantifying just how vast the space of latent "overhung" LLM capabilities really is constitutes a major area of formal and enthusiast-driven inquiry. ToM is one such highly compelling research domain. Kosinski3 shows that the OpenAI GPT-series of models possess the ability to pass fundamental developmental behavior tests. Some papers demonstrate how to improve these abilities16 and others analyze these methods critically, questioning the premise of ToM emerging in LLMs1718.
Adjacently, there's a clear trend of researchers pushing the limit of what types of cognitive tasks can be offloaded to LLMs. In order to scale supervision, eliminate human feedback, avoid evasive responses, and have transparent governing principles, Anthropic has experimented with delegating the work of human feedback to the LLM itself in their "constitutional" approach19. Other papers looking to achieve similar types of outcomes, without needing to update model weights, rely on in-context methods entirely2021.
Violation of Expectation
One prime task candidate, which leverages emergent ToM abilities, is VoE. Similar to explanations from PC theories of cognition, VoE is an explicit mechanism that reduces prediction errors to learn about reality.
While much of VoE happens in the unconscious mind and from an early age4, research suggests that deliberate prediction making and error reduction also leads to enhanced learning outcomes5.
Just as PC may play a role in ToM, VoE is a lightweight framework for identifying the data needed to minimize ToM error. Predicts are generated, compared against percepts, and learning is derived from the difference.
Prompting Paradigms
Chain-of-Thought6 prompting clearly shows that LLMs are capable "reasoning" generators and that this species of prompting can reduce the probability of generating incorrect answers. Yet, as this method is limited to one inference, the model often disregards that reasoning, especially during ToM-related tasks.
Metaprompt Programming7 seeks to solve the laborious process of manually generating task-specific prompts (which are more efficacious than general ones) by leveraging LLMs' ability to few-shot prompt themselves dynamically.
Deliberate VoE as learning method, ToM, and these prompting approaches all echo the human phenomenon of metacognition — put simply, thinking about thought. In the next section we introduce a metacognitive prompting framework in which the LLM generates ToM "thoughts" to be used in further generation as part of a VoE framework to passively acquire psychological data about the user.
4. Methods
The cognitive mechanism VoE can be broken down into two circular steps:


Making predictions about reality based on past learning.


Learning from the delta between predictions and reality.


In the typical chat setting of a conversational LLM application, this means making a prediction about the next user input and comparing that with the actual input in order to derive psychological facts about the user at each conversational turn. We employ metacognitive prompting across both core parts of our framework shown in Figure 1: our user prediction task and our violation of expectation task.

Figure 1: Framework. Contained in the grey dotted box is an application's core conversation loop (e.g. our AI tutor, Bloom) and drawn in blue is the metacognitive prompting framework described in section 4.
4.1 Metacognitive Prompting
Synthesized from the influences mentioned in Section 3, we introduce the concept of metacognitive prompting. The core idea is prompting the model to generate "thoughts" about an assigned task, then using those "thoughts" as useful context in the following inference steps. We find that in practice, this method of forced metacognition enhances LLM ability to take context into account for ToM tasks (more discussion in Section 7.2, "Measuring Coherence").
Task 1: User Prediction and Revision. Given history of the current conversation, we prompt the LLM to generate a ToM thought including:


Reasoning about the user's internal mental state


Likely possibilities for the next user input


A list of any additional data that would be useful to improve the prediction


The list serves as a query over a vector store to retrieve relevant VoE derived user facts from prior interactions.
We then prompt the model in a separate inference to revise the original ToM thought given new information, i.e. the retrieved facts that have been derived and stored by VoE. These facts are psychological in nature and taken into account to produce a revision with reduced prediction error.
Task 2: Violation of Expectation and Revision. We employ the same prompting paradigm again in the VoE implementation.
The first step is to generate a "thought" about the difference between prediction and reality in the previous user prediction task. This compares expectation — the revised user prediction — with violation — the actual user input. That is, how was expectation violated? If there were errors in the user predictions, what were they and why?
This thought is sent to the next step, which generates a fact (or list of facts). In this step, we include the following:


Most recent LLM message sent to the user


Revised user prediction thought


Actual user response


Thought about how expectation was violated


Given this context, fact(s) relevant to the user's actual response are generated. This generation constitutes what was learned from VoE, i.e. prediction errors in ToM.
Finally, we run a simple redundancy check on the derived facts, then write them to a vector store. We used the OpenAI Embeddings API for the experiment in this paper.
5. Experiments
Our experiment aims to show that using VoE derived data reduces error in LLM prediction about the next user input. This is especially useful and testable in conversations, so we use data from our AI tutor, Bloom, which is specifically prompted to keep a conversation moving forward to produce learning outcomes for users.
Traditional conversation datasets often lean toward trivial dialogue, while instruction-following datasets are predominantly one-sided and transactional. Such datasets lack interpersonal dynamics, offering limited scope for substantive social cognition. Thus, our experiment employs an A/B test with two versions of our AI tutor, conversations with which more closely reflect psychologically-informative social interactions between humans.
The first version — the control — relies solely on past conversation to predict what the user will say next. Yet the second version — the experimental — uses our metacognitive prompting framework in the background to make predictions. Crucially, and as described in Section 4, the framework leverages VoE to increase the amount of information at the model's disposal to predict user responses. These VoE facts are introduced to the AI tutor through the additional "thought revision" phase in the conversational loop, allowing it to reduce prediction error and psychologically cohere itself more closely to the user.
We use the same LLM — GPT-4 — to classify how well each version predicts each user input. Its assessment is useful to discern whether VoE data can reduce LLM prediction error as LLMs are competent arbiters of token similarity.
We do so by prompting GPT-4 to choose from 5 options that assess the degree to which a generated user prediction thought is accurate. The choices include "very," "somewhat," "neutral," "poorly," and "wrong." We include the most recent AI message, thought prediction, and actual user response in the context window. The evaluation scripts can be found on GitHub.
6. Results
Dataset
This experiment uses a dataset of conversations users had with Bloom. We built it by running an A/B test on the backend of Bloom's web interface. Only conversations of 3 or more turns are included. We recorded 59 conversations where the VoE version was active and 55 conversations where it was not. Within those, we collected 329 message examples from the VoE version and 637 from the non-VoE version. More on that difference in the "Considerations" paragraph in this section.
| Assessment | VoE N | VoE Pct | Non-VoE N | Non-VoE Pct |
|------------|-------|---------|-----------|-------------|
| 1. Very | 35 | 0.106 | 96 | 0.151 |
| 2. Somewhat | 78 | 0.237 | 77 | 0.121 |
| 3. Neutral | 17 | 0.052 | 22 | 0.035 |
| 4. Poorly | 90 | 0.274 | 170 | 0.267 |
| 5. Wrong | 109 | 0.331 | 272 | 0.427 |
Figure 2: Results from A/B test in the Bloom Web UI.
Chi Square Test
We chose to give the model freedom to choose more granular assessments like values "somewhat", "neutral", and "poorly" rather than forcing it into a binary classification, but we found it barely used the "neutral" option. On a five-point scale, the top two ratings ("very" and "somewhat" predictions) are grouped as "good", neutral ratings are omitted from the analysis, and the lowest two ratings ("poorly" and "wrong") are grouped as "bad".
We want to test the independence of two categorical variables: assessment (good or bad) and group (VoE or non-VoE). The observed frequencies are given in the following table:
| | VoE | Non-VoE |
|------|-----|---------|
| Good | 113 | 173 |
| Bad | 199 | 442 |
The Chi-square test statistic is calculated as:
χ2=∑Eij​(Oij​−Eij​)2​
where Oij​ are the observed frequencies and Eij​ are the expected frequencies under the null hypothesis of independence. The expected frequencies are calculated as:
Eij​=grand total(row totali​)(column totalj​)​
For each cell, we calculate the expected frequency and then the contribution to the Chi-square statistic. The degrees of freedom for the test are (R−1)(C−1), where R is the number of rows and C is the number of columns.
The Chi-Square Test indicated a significant relationship between assessment and group, χ2(1,927)=5.97, p<.05, such that VoE predictions were evaluated as good more often than expected and bad less often than expected. These results support our hypothesis that augmenting the Bloom chatbot with VoE reasoning reduces the model's error in predicting user inputs.
Reducing Prediction Errors
The VoE version showed a significant reduction in prediction errors, resulting in fewer "wrong" values being generated. Overall, the VoE version exhibited a smoothing effect, enhancing the consistency of predictions. Although there was a slight decrease in "very" predictions, a relative increase of 51% in "somewhat" values was observed. This shift suggests an improvement in prediction fidelity, balancing out extreme predictions with more moderate ones. Notably, the VoE version generated 22.4% fewer "wrong" predictions compared to the Non-VoE version.

Figure 3: Plot of results found in Figure 2. VoE smooths the distribution of predictions, reducing prediction error by learning from prior generations. This echoes accounts of human learning described in PC and VoE theories.
Considerations
The inherent nature of VoE is to improve and refine over time. As the vector store becomes populated with more data, the accuracy and relevance of VoE's outputs are expected to increase, enabling more valuable responses for users.
It's important to note the presence of latency in VoE Bloom. This likely contributed to the reduction in conversation turns to nearly half that of the non-VoE Bloom. Nevertheless, the fact we observe a statistical difference between the groups given this discrepancy in data size is noteworthy.
There are a number of other practical factors in our data that might inhibit our ability to accurately measure the degree to which user prediction error was minimized. We used our conversational AI tutor's data for this study, which is subject to various issues that are being faced by all consumer-facing AI applications. This technology is new, and people are still learning how to interface with it. Many users ask Bloom to search the internet, do mathematical computations, or other things that aren't well served by the prompting framework around GPT-4.
Finally, it's of conceptual interest that LLMs can, from prompting alone, reduce prediction errors via mechanisms similar to those posited by PC and VoE theories of human cognition.
7. Future Work and Beyond
7.1 Improvements
Retrieval Augmented Generation. Currently, our VoE fact retrieval schemes are quite naive. The "thought" generation steps are prompted to generate thoughts and additional data points that would help improve the prediction. Those additional data points serve as a basic semantic similarity query over a vector store of OpenAI embeddings, and we select top k entries. Much could be done to improve this workflow, from training custom embedding models to improving the retrieval method. We also draw inspiration from the FLARE paper22 and note the improved generation results that come from forecasting a conversation and incorporating that into the context window.
Training/Fine-Tuning. Similar to how instruction tuning yielded much improved results in decoder-only LLMs, we believe that ToM tuning is a task that could yield better psychological models. The task of following instructions is a sufficiently abstract idea. Making ToM predictions falls into the same category.
7.2 Evaluation
Assessing Theory of Mind. The authors of "Clever Hans or Neural Theory of Mind? Stress Testing Social Reasoning in Large Language Models"18 explicitly state that "the consequences of the success of these tests do not straightforwardly transfer from humans to models" and speak at length to the evolving landscape of datasets and evaluation methods aimed at machines instead of humans. The debate about whether or not LLMs "have" ToM is likely to continue and more semantic definitional work also needs to be done, but what's undeniable is the utility of this capability. Specifically interesting is boosting the performance of LLMs to minimize user prediction error, as much may become possible as a result of gains in that domain.
Measuring Coherence. For this paper, we exclusively leverage OpenAI's closed-source models behind their API endpoints. Because of this, we are fundamentally limited in the ways in which we can measure user prediction error. In order to remain consistent, we have the same LLM that is generating the ToM predictions generate a naive assessment of its accuracy, which is described more in Section 5.
Experiments with open source LLMs allow much more granular evaluation. E.g. computing the conditional loss over a sequence of tokens or creating new datasets by employing human labelers to train an evaluation model. Establishing a more rigorous standard around evaluating ToM predictions with multi-turn interpersonal conversation data is an imperative area of work as well.
The space of open source models is relatively untested in regard to ToM abilities. Comprehensive study of how the open source model stable performs on already existing tasks is a crucial next step.
Still further challenges exist in establishing reliable evaluation methods for measuring LLM coherence to users. Each user possesses not only unique psychological properties, but varying levels of awareness of that psychological profile. These subjective limitations demand novel approaches, research into which is only now becoming possible.
7.3 Utility
Infrastructure. In a world of abundant synthetic intelligence, if vertical-specific AI applications remain viable, they will seek to outperform foundational models within their narrow purview. Redundantly solving personalization and psychological modeling problems represents unnecessary development and data governance overhead and risks contaminating datasets. Nor is it in the security or temporal interest of users to share such data. Horizontal frameworks and protocols are needed to safely and efficiently manage these data flows, improve user experience, and align incentives.
Products. Ability to robustly model user psychology and make ToM predictions about internal mental states represents novel opportunity for the frontier of goods and services. Bespoke multimodal content generation, high-fidelity human social simulation, on-demand disposable software, atomization of services, instant personalization, and more could all become possible. Much work will be needed to explore this design space.
7.4 Security
While ToM data holds powerful personalization potential, the management and use of that data entails profound responsibility and promises significant hazards. Such data, rich with insights into internal user identity and future behavior suggests immense utility. Yet, this utility makes it a likely target for misuse or object of mishandling — more so given the remarkable inferential capabilities of LLMs.
Security implications are far-reaching, from privacy invasion and identity theft to manipulation and discrimination. Moreover, any breach of trust impacts not just individual users, but the reputation and success of organizations employing it. Below is a non-exhaustive list of future work needed to secure such data throughout its lifecycle.
Encryption and Custody. Due to the sensitive, individual nature of ToM data, encryption is a bare minimum security requirement, and there are strong arguments to be made for direct user key ownership. Formal investigations into appropriate solutions to both are needed.
The process of transforming plaintext to ciphertext safeguards the data from keyless access. Several methods of encryption, including symmetric methods like the Advanced Encryption Standard, which uses the same key for encryption and decryption, and asymmetric encryption methods like RSA, which uses two keys, a public key for encryption and a private key for decryption23, are plausible candidates.
Models for key management will dictate the exact implementation of encryption against the data. A method such as Shamir's secret sharing can be used to split the decryption key between a user and a trusted platform hosting the data24. However, the intimate nature of the data may still warrant user ownership, preventing even the platform from accessing the data.
Confidential Computing. This relatively new technology encrypts data in use (i.e. during processing). Confidential computing is a step beyond traditional methods that encrypt data at rest and in transit, thus providing a more comprehensive data protection framework. It leverages hardware-based Trusted Execution Environments (TEEs) to protect data during computation, enabling sensitive data to be processed in the cloud or third-party environments without exposing it to the rest of the system25.
Further work can determine architectures for safely mounting user data into TEEs, decrypting, and then using it to improve interactions between users and LLMs. Work to explore how to create a scalable and performant design that does not sacrifice security is needed. Additional considerations need to be made for securely using data with third-party LLM APIs such as OpenAI's GPT-4 as opposed to self-hosted models.
Policy-Based Access Control. Policy-Based Access Control (or Attribute Based Policy Control) is a method used to regulate who or what can view or use resources in a computing environment26. It's based on creating, managing, and enforcing rules for accessing resources to define the conditions under which access is granted or denied.
Policies that can be applied on the data to ensure principles of least privilege to client applications and prevent data leakage are directions for further inquiry. LLM applications could be used to extend the policies to allow attributes based on the content of the data, such as grouping by topic.
Frontier Security. LLMs' powerful inference abilities place them in a new category of digital actors. New paradigms of protection and security will be required. LLMs themselves might be leveraged to proactively monitor and obfuscate user activity or destroy unwanted statistical relationships. The advent of instant personalization may even make persistent application-side user accounts irrelevant or unsustainably hazardous.
7.5 Philosophy
Extended Self. Chalmers and Clark argued in 1998 that minds can be said to extend into the physical world and still legitimately be considered part of personal cognition27. High-fidelity human psychological renderings in AI agents suggest the potential for human agency and identity to extend in similar ways. Unanswered legal, metaphysical, and ethical questions arise from this prospect.
Phenomenology. When humans impute mental states to others, presumably that assignment is grounded in lived personal experience. That is, we can imagine other people having experiences because we have had similar experiences ourselves. Additionally, we share with the objects of our ToM a genetic schema and physical substrate for intelligence and social cognition.
While LLMs display ToM abilities and may well have access to orders of magnitude more accounts of internal mental states via the massive corpus of their pretraining data, none of that has been experienced first hand. Leaving aside that current LLMs likely have no mechanism for experience as we conceive of it28, what are we to make of ToM in such alien minds?
Game Theory. Our experiments and testing protocol assume users are unwise to model predictions about them. As users become aware that models are actively predicting their mental states and behavior, those predictions may become harder to make. Similarly, as LLMs take this into account, simulations will become still more complex.
8. Discussion
Principal-agent problems are a set of well understood coordination failures that emerge from interest misalignment and information asymmetry between persons or groups and their proxies. In normal political and economic life, delegating an agent incurs costs and efforts to minimize that risk reduce the efficiency of the agent.
We view our very early work in modeling user psychology as ultimately in service of eliminating the certitude of principal-agent problems from economic relations. As LLMs or other AI systems become increasingly capable and autonomous, they offer enormous economic potential. However, their alignment to human principals is not a foregone conclusion. On the contrary, we may instead see an exaggeration of existing asymmetries between principals and agents, as well as the introduction of new concerns around latency, intelligence, and digital nativity.
In order to achieve trustworthy and efficient agentic AI, individual alignment is required. Human agents and deterministic software are already capable of operating like their principals. LLMs promise massive reductions in marginal cost along that axis, but hardly class better than the status quo (and often much worse) with regard to user alignment. Yet the unique potential here is agents who are the principals themselves, that is, there is no meaningful practical or philosophical difference between discrete humans and the psychologically-aligned AIs acting on their behalf.
LLMs are excellent simulators capable of assuming myriad identities29. They also excel at ToM tasks, and we've shown, can passively harvest and reason about user psychological data. These two interrelated qualities may very well make possible high-fidelity renderings of principals capable of flawlessly originating and executing intent as their proxies with zero marginal agency cost. In this way LLMs may become more augmentation than tool, more appendage than agent.
9. Acknowledgements
The authors are grateful to Ayush Paul and Jacob Van Meter for their work on the Bloom development team, Thomas Howell of Forum Education for extensive conceptual review and ideation, and Zach Seward for invaluable advice and mentoring. We are additionally grateful to Ben Bowman for advising the machine learning aspects of this paper and Lee Ahern from the Bellisario College of Communications at Pennsylvania State University for feedback on the statistical tests and results section.
References

Footnotes


Michael C Jensen and William H Meckling. "Theory of the firm: Managerial behavior, agency costs and ownership structure". In: Corporate governance. Gower, 2019, pp. 77–132. ↩


Jason Wei et al. "Emergent Abilities of Large Language Models". 2022. arXiv: 2206.07682 [cs.CL]. ↩ ↩2


Michal Kosinski. "Theory of Mind May Have Spontaneously Emerged in Large Language Models". 2023. arXiv: 2302.02083 [cs.CL]. ↩ ↩2


Kristine H Onishi and Renée Baillargeon. "Do 15-month-old infants understand false beliefs?" In: Science 308.5719 (2005), pp. 255–258. ↩ ↩2


Garvin Brod et al. "Explicitly predicting outcomes enhances learning of expectancy-violating information". In: Psychonomic bulletin & review 29.6 (2022), pp. 2192–2201. ↩ ↩2


Jason Wei et al. "Chain-of-thought prompting elicits reasoning in large language models". In: Advances in Neural Information Processing Systems 35 (2022), pp. 24824–24837. ↩ ↩2 ↩3


Laria Reynolds and Kyle McDonell. "Prompt programming for large language models: Beyond the few-shot paradigm". In: Extended Abstracts of the 2021 CHI Conference on Human Factors in Computing Systems. 2021, pp. 1–7. ↩ ↩2


GPT-4 32k version: 0613 ↩


Wolfram Schultz, Peter Dayan, and P Read Montague. "A neural substrate of prediction and reward". In: Science 275.5306 (1997), pp. 1593–1599. ↩


Tommaso Salvatori et al. "Brain-Inspired Computational Intelligence via Predictive Coding". 2023. arXiv: 2308.07870 [cs.AI]. ↩


Jorie Koster-Hale and Rebecca Saxe. "Theory of mind: a neural prediction problem". In: Neuron 79.5 (2013), pp. 836–848. ↩


Tom Brown et al. "Language models are few-shot learners". In: Advances in neural information processing systems 33 (2020), pp. 1877–1901. ↩


Takeshi Kojima et al. "Large Language Models are Zero-Shot Reasoners". 2023. arXiv: 2205.11916 [cs.CL]. ↩


Shunyu Yao et al. "ReAct: Synergizing Reasoning and Acting in Language Models". 2023. arXiv: 2210.03629 [cs.CL]. ↩


Sheng Lu et al. "Are Emergent Abilities in Large Language Models just In-Context Learning?" 2023. arXiv: 2309.01809 [cs.CL]. ↩


Shima Rahimi Moghaddam and Christopher J. Honey. "Boosting Theory-of-Mind Performance in Large Language Models via Prompting". 2023. arXiv: 2304.11490 [cs.AI]. ↩


Tomer Ullman. "Large Language Models Fail on Trivial Alterations to Theory-of-Mind Tasks". 2023. arXiv: 2302.08399 [cs.AI]. ↩


Natalie Shapira et al. "Clever Hans or Neural Theory of Mind? Stress Testing Social Reasoning in Large Language Models". 2023. arXiv: 2305.14763 [cs.CL]. ↩ ↩2


Yuntao Bai et al. "Constitutional AI: Harmlessness from AI Feedback". 2022. arXiv: 2212.08073 [cs.CL]. ↩


Noah Shinn et al. "Reflexion: Language Agents with Verbal Reinforcement Learning". 2023. arXiv: 2303.11366 [cs.AI]. ↩


Aojun Zhou et al. "Solving Challenging Math Word Problems Using GPT-4 Code Interpreter with Code-based Self-Verification". 2023. arXiv: 2308.07921 [cs.CL]. ↩


Zhengbao Jiang et al. "Active Retrieval Augmented Generation". 2023. arXiv: 2305.06983 [cs.CL]. ↩


"A method for obtaining digital signatures and public-key cryptosystems". In: Communications of the ACM 21.2 (1978), pp. 120–126. ↩


Ed Dawson and Diane Donovan. "The breadth of Shamir's secret-sharing scheme". In: Computers & Security 13.1 (1994), pp. 69–78. ↩


Confidential Computing Consortium et al. "Confidential computing: Hardware-based trusted execution for applications and data". In: A Publication of The Confidential Computing Consortium July 2020 (2020). ↩


Vincent C Hu et al. "Guide to attribute based access control (abac) definition and considerations (draft)". In: NIST special publication 800.162 (2013), pp. 1–54. ↩


Andy Clark and David J. Chalmers. "The Extended Mind". In: Analysis 58.1 (1998), pp. 7–19. doi: 10.1093/analys/58.1.7. ↩


David J. Chalmers. "Could a Large Language Model be Conscious?" 2023. arXiv: 2303.07103 [cs.AI]. ↩


janus. "Simulators". Sept. 2022. url: generative.ink/posts/simulators/. ↩




---

### ARCHIVED: Theory-of-Mind Is All You Need

How giving LLMs autonomy to reason about user psychology through theory-of-mind predictions dramatically improves AI tutoring & learning experiences.

Date: 2023-06-12
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-Theory-of-Mind-Is-All-You-Need
Tags: blog, ml, bloom, pedagogy, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post concerns Bloom, our Honcho-powered AI-tutor. We've suspended Bloom to focus exclusively on Honcho.
Plastic started as an EdTech company, with Bloom as its main product. In building a popular, first-of-its-kind personalized AI tutor, we realized three things (1) all agents will soon need continuous learning systems to understand their users, (2) this an extremely hard problem that every developer shouldn't have to redundantly solve, & (3) we were uniquely positioned to solve it.
So we pivoted to Honcho, keeping Bloom around for a while as a demo.
We wrote the following at the very beginning of that transition. The content here gets into the emergent LLM theory of mind capabilities we were exploring at the time, agentic auto-prompting, and the positive effects of personalizing agents--all quite a bit ahead of its time.
Enjoy.


TL;DR
Today we’re releasing a major upgrade to Bloom (& the open-source codebase, tutor-gpt).
We gave our tutor even more autonomy to reason about the psychology of the user, and—using GPT-4 to dynamically rewrite its own system prompts—we’re able to dramatically expand the scope of what Bloom can do and massively reduce our prompting architecture.
We leaned into theory of mind experiments and Bloom is now more than just a literacy tutor, it’s an expansive learning companion.
Satisfying Objective Discovery
Bloom is already excellent at helping you draft and understand language. But we want it do whatever you need.
To expand functionality though, we faced a difficult technical problem: figuring out what the learner wants to do.
Sounds simple (just ask), yet any teacher will tell you, students are often the last to understand what they ought to be doing. Are you learning for its own sake, or working on an assignment? What are the expectations and parameters? What preferences do you have about how this gets done?
Explaining all this to a tutor (synthetic or biological) upfront, is laborious and tiresome. We could just add some buttons, but that’s a deterministic cop-out.

What expert educators will do is gather more information throughout the completion of the task, resolving on a more precise objective along the way; keeping the flow natural, and leaving the door open to compelling tangents and pivots.
The key here is they don’t have all the information—they don’t know what the objective is precisely—but being good at tutoring means turning that into an advantage, figuring it out along the way is optimal. The effective human tutor dynamically iterates on a set of internal models about student psychology and session objectives. So how do we recreate this in Bloom?
Well we know that (1) foundation models are shockingly good at theory of mind, (2) Bloom already excels at pedagogical reasoning, and (3) autonomous agents are having early success, so what if we stopped trying to deterministically prescribe an indeterminant intelligence?
What if we treated Bloom with some intellectual respect? 
Autonomous Prompting
The solution here is scary simple. The results are scary good.
Here’s a description of the previous version’s architecture:
Transclude of ARCHIVED;-Open-Sourcing-Tutor-GPT#^285105
Transclude of ARCHIVED;-Open-Sourcing-Tutor-GPT#^1e01f2
Transclude of ARCHIVED;-Open-Sourcing-Tutor-GPT#^b1794d
Instead, we’ve now repurposed the thought chain to do two things:

Predict the user’s unobserved mental state
List the information needed to enhance that prediction


Then we inject that generation into the body of the response chain’s system prompt. We do this with every user input. Instead of just reasoning about the learner’s intellectual/academic needs, Bloom now proactively rewrites itself to be as in-tune as possible to the learner at every step of the journey.
Emergent Effects
We’re seeing substantial positive behavior changes as a result of giving Bloom this kind of autonomy.

Bloom is more pleasant to converse with. It’s still Socratic and will still push you to learn, but it’s not nearly as restrictive. Mainly, we posit this is a result of the tutor cohering to the user. Bloom becomes more like its interlocutor, it’s in many ways a mirror. This has a positive psychological effect—think of your favorite teacher from high school or college.

And Bloom is game. It’ll go down a rabbit hole with you, help you strategize around an assignment, or just chat. Bloom displays impressive discernment between acting on theory of mind recommendations to gather more information from you and asking topically-related questions to keep up the momentum of the conversation. It’s no longer obsessed with conforming to the popular stereotype of a tutor or teacher.

While reducing the prompt material, we took to opportunity to remove basically all references to “tutor,” “student,” etc. We found that since Bloom is no longer contaminated by pointing at certain averaged narratives in its pre-training—e.g. the (bankrupt) contemporary conception of what a tutor is ‘supposed’ to be—it is, ironically, a better one.
Instead of simulating a tutor, it simulates you.
Coming Soon...
All this begs the question: what could Bloom do with even better theory of mind? And how can we facilitate that?
What could other AI applications do with a framework like this?
Stay tuned.

---

### ARCHIVED: Open-Sourcing Tutor-GPT

Open-sourcing Bloom, our AI learning companion that uses metacognitive prompting to elicit pedagogical reasoning & theory-of-mind from LLMs.

Date: 2023-06-02
URL: https://blog.plasticlabs.ai/archive/ARCHIVED;-Open-Sourcing-Tutor-GPT
Tags: blog, bloom, announcements, pedagogy, ml, archive



                  
                  WELCOME TO THE PLASTIC ARCHIVE
                  
                

This blog post has been archived because it's legacy content that's out-of-date or deprecated. We keep this content around so those interested can dig into the evolution of our projects & thinking.
This post concerns Bloom, our Honcho-powered AI-tutor. We've suspended Bloom to focus exclusively on Honcho.
Plastic started as an EdTech company, with Bloom as its main product. In building a popular, first-of-its-kind personalized AI tutor, we realized three things (1) all agents will soon need continuous learning systems to understand their users, (2) this an extremely hard problem that every developer shouldn't have to redundantly solve, & (3) we were uniquely positioned to solve it.
So we pivoted to Honcho, keeping Bloom around for a while as a demo.
We wrote the following at the very beginning of that transition. It details the benefits of early efforts at model reasoning to enhance personalization, architecture that would later inspire Honcho, & the massive space overhung LLM capabilities we were researching--all quite a bit ahead of its time.
Enjoy.



TL;DR
Today we’re open-sourcing Bloom, our digital Aristotelian learning companion.
What makes Bloom compelling is its ability to reason pedagogically about the learner. That is, it uses dialogue to posit the most educationally-optimal tutoring behavior. Eliciting this from the capability overhang involves multiple chains of metaprompting enabling Bloom to construct a nascent, academic theory of mind for each student. 
We’re now seeing this in the explosion of ‘chat-over-content’ tools, most of which fail to capitalize on the enormous latent abilities of LLMs. Even the impressive out-of-the-box capabilities of contemporary models don’t achieve the necessary user intimacy. Infrastructure for that doesn’t exist yet 👀.
Our mission is to facilitate personal, agentic AI for all. So to that end, we’re (1) releasing Bloom’s architecture into the wild and (2) embarking on a journey to supercharge the kind of empowering generative agents we want to see in the world.
Neo-Aristotelian Tutoring
Right now, Bloom is a reading comprehension and writing workshop tutor. You can chat with it in Discord. After supplying it a passage, Bloom can coach you toward understanding or revising a piece of text. It does this by treating the user as an equal, prompting and challenging socratically.
We started with reading and writing in natural language because (1) native language acumen is the symbolic system through which all other fluencies are learned, (2) critical dialogue is the ideal vehicle by which to do this, and (3) that's what LLMs are best at right now.
The problem is, most students today don't have the luxury of "talking it out" with an expert interlocutor. But we know that's what works. (Perhaps too) heavily referenced in tech and academia, Bloom’s 2 sigma problem suggests that students tutored 1:1 can perform two standard deviations better than classroom taught peers.
Current compute suggests we can do high-grade 1:1 for two orders of magnitude cheaper marginal cost than your average human tutor. It may well be that industrial education ends up a blip in the history of learning—necessary for scaling edu, but eventually supplanted by a reinvention of Aristotelian models.

It's clear generative AI stands a good chance of democratizing this kind of access and attention, but what's less clear are the specifics. It's tough to be an effective teacher that students actually want to learn from. Harder still to let the student guide the experience, yet maintain an elevated discourse.
So how do we create successful learning agents that students will eagerly use without coercion? We think this ability lies latent in foundation models, but the key is eliciting it.
Eliciting Pedagogical Reasoning
^x527dc
The machine learning community has long sought to uncover the full range of tasks that large language models can be prompted to accomplish on general pre-training alone (the capability overhang). We believe we have discovered one such task: pedagogical reasoning. 
Bloom was built and prompted to elicit this specific type of teaching behavior. (The kind laborious for new teachers, but that adept ones learn to do unconsciously.) After each input it revises a user’s real-time academic needs, considers all the information at its disposal, and suggests to itself a framework for constructing the ideal response. 

It consists of two “chain” objects from LangChain —a thought and response chain. The thought chain exists to prompt the model to generate a pedagogical thought about the student’s input—e.g. a student’s mental state, learning goals, preferences for the conversation, quality of reasoning, knowledge of the text, etc. The response chain takes that thought and generates a response. 
Each chain has a ConversationSummaryBufferMemory object summarizing the respective “conversations.” The thought chain summarizes the thoughts into a rank-ordered academic needs list that gains specificity and gets reprioritized with each student input. The response chain summarizes the dialogue in an attempt to avoid circular conversations and record learning progress. 
We’re eliciting this behavior from prompting alone. Two of Plastic’s co-founders have extensive experience in education, both in private tutoring and the classroom. They crafted strong example dialogues that sufficiently demonstrated how to respond across a range of situations.
Take for example a situation where the student asks directly for an answer. Here is Bloom’s response compared to Khanmigo’s:



Khanmigo chides, deflects, and restates the question. Bloom levels with the student as an equal—it’s empathetic, explains why this is a worthwhile task, then offers support starting from a different angle…much like a compassionate, effective tutor. And note the thought that also informed its response — an accurate imputation of the student’s mental state.
And Bloom is dynamic, even when given no excerpted context and asked about non-textual material, it’s able to converse naturally about student interest:

And its accompanying thoughts:

Notice how Bloom reasons it should indulge the topic, validate the student, and point toward (but not supply) possible answers. Then the resultant responses do this and more, gently guiding toward a fuller comprehension and higher-fidelity understanding of the music.
Aside from these edgier cases, Bloom shines helping students understand difficult passages (from syntactic to conceptual levels) and giving writing feedback (especially competent at thesis construction). Take it for a spin.
Ultimately, we hope open-sourcing Bloom will allow anyone to run with these elicitations and prompt to expand utility and support multiple domains. We’ll be doing work here too.
Bloom & Agentic AI
This constitutes the beginning of an approach far superior to just slapping a chatbot UI over a content library that's probably already in the foundation model's pre-training.
After all, if it were just about content delivery, MOOCs would've solved education. We need more than that to reliably grow rare minds. And we're already seeing Bloom excel at promoting synthesis and creative interpretation within its narrow utility.
But to truly give students superpowers and liberate them from the drudgery that much of formal education has become, Bloom needs to go further. Specifically, it needs to both proactively anticipate the needs of the user and execute autonomously against that reasoning.
It needs to excel at theory of mind, the kind of deep psychological modeling that makes for good teachers. In fact, we think that lots of AI tools are running up against this problem too. So what we're building next is infrastructure for multi-agent trustless data exchange. We think this will unlock a host of game-changing additional overhung capabilities across the landscape of artificial intelligence.
If we’re to realize a world where open-source, personalized, and local models are competitive with hegemonic incumbents, one where autonomous agents represent continuous branches of truly extended minds, we need a framework for securely and privately handling the intimate data required to earn this level of trust and agency.

---