# Sunsetting SocioTechnica Friends and followers, tl;dr: We have decided to shut down SocioTechnica. On August 11th, Danvers and I made the unanimous decision to step away from SocioTechnica and separately pursue other things. I will get into the why of the decision shortly. But given that this our last update I also wanted to take time and look back on SocioTechnica's circuitous journey, reflect on some lessons learned, and point forward to the road ahead. Why are we shutting it down? The short answer is SocioTechnica never became a sustainable entity, in two senses. From a financial perspective, SocioTechnica required Danvers and I to continually support the efforts through our time and money from other endeavors. But perhaps more importantly, we never gave birth to a sustained product in the world. There is no lively open source project or production software product demanding care and growth. Put simply, SocioTechnica was effective as a tool to explore ideas, yet those ideas failed to find any permanence or purchase in the world. After a little over two years of exploratory effort without anything sustainable to show for it, we decided it was time to shift our attentions to other things. But what of the ideas? What of the explorations? If you'll indulge me, I'd like to take you on a little tour through the projects and ideas we worked on and then to reflect on what we learned and what remains to be done. ## The Story of SocioTechnica Danvers and I have been partnering on various projects since 2008. But in the latest incarnation of the partnership, our story beings in July 2024. What follows is a fast-paced tour of July 2024 to August 2026. ### Next LX: July 2024 - December 2024 A few years earlier, Danvers and I worked together at an online school teaching software development. We designed an "experiential learning" environment where students learned software engineering skills by doing real work, building production software for non-profits and internal tooling. It was incredibly effective, but one of the things we lamented is that the real work was _too_ variable. One team might learn a particular lesson due to an interaction with the client, while another might learn something about a production system going down during an important meeting. What was needed was a "flight simulator for office work," an environment where failures could be scripted with care and introduced adaptively based on the trainee's learning needs. In mid-2024, it wasn't clear that LLMs could do real, economically valuable work yet as true employees. But what if an LLM merely _simulated_ the work that is done in an remote work office setting, pretending to be the employees? Just like the graphics of a flight simulator don't have to match reality in order for it to be effective for training, perhaps LLMs doing simulated, middling work would be an effective training environment for human learners. It was an uphill battle to get this to work. The frontier models were GPT 4o and Claude 3.5 Sonnet. Agent architecture wasn't even a conversation. Evals were at the level of individual prompt + response. SaaS office software lacked account support for agents and MCP hadn't been invented yet. Nevertheless, it sorta worked. Agents chatting in Discord, updating work in Trello, creating Google Docs. It felt novel and pretty magical. An investor we spoke to about Next LX said something prophetic: > If this actually works, you won't use it for training humans. Two years later, it does work. And we definitely don't use it for training humans. But maybe we should? Fascinating idea, but we couldn't find a way to bring it to market (foreshadowing!). ### Pat Sharpe, NFT Trader: Dec 2024 - April 2025 The more we worked with the AI coworkers, we started to see glimmers that they could do real, economically valuable work. How could we find out? What's clearly economically valuable? Buy low, sell high! Thus Pat Sharpe, our AI intern, was born. Danvers was intimately knowledgable about basketball and the NBA Top Shot NFT marketplace, so we decided to set Pat to work buying and selling basketball NFTs. This was a fun period of SocioTechnica; actual money flowing! Much like Next LX, it felt like we were fighting the technology and (barely) winning. Claude Computer use launched in February, but it was comically bad. Scraping web pages to get the market data was painful. Automating the browser to click the buttons to buy and sell was constantly breaking. Models still sucked at instruction following and we had to break down everything into micro-prompts that were rigorously eval'd; after all, this model has our credit card! Eventually, we got it working enough to start making about $5/day in profit. We brought Pat into our Discord and started instrumenting all of his actions via chat. Again, this was starting to feel magical, but $5/day was not even ramen levels of profitability. If we were going to scale up profit, we would need dozens of Pats. Pat wasn't built to scale; he was an existence proof: LLMs can do economically valuable work. ### WorkSquared: March 2025 - July 2025 That spring, Danvers had been increasingly using AI in his consulting gig and getting good work. The challenge was keeping track of it all and coordinating it. The "platforms" of the time were ChatGPT and Claude.ai or use the API directly. Claude Code had started to gain popularity, but it was focused on software engineering tasks. To scale up our LLM colleagues, we needed both a shared data layer and a management interface. At this point, I'd been trying to build LLM-powered agents for about 10 months and something finally clicked in terms of the architecture: it's an event stream. I wrote a technical note in early April outlining how to build a [multiplayer data layer for agents](https://sociotechnica.org/notebook/ws-tech-foundations/). Reading back through it now, I think it was mostly correct: build on an event stream aka sync engine, give agents self-extension through tool building (i.e., code mode), direct manipulation for users, a canvas for flexible media types. I didn't figure out context management (Danvers did a few months later!) In addition to the platform for the agents, we also needed some way to visually manage all of the agentic work that was happening across the organization. Danvers did a few explorations here, but nothing really stuck. It took several months to really get the WorkSquared platform working. The technical foundations lab note described the high-level, but the devil was in the details. Once we had a work first version, we were in search of a use case to really prove it out. And we found one: our personal lives. ### LifeBuild: August 2025 - February 2026 Life comes at you hard in your 40s. Danvers and I have families and kids to care for, households to manage, relationships to tend, etc. Life is rich and full, and in need of perpetual maintenance. LLMs were doing genuinely useful work for us at this point. Naturally, we were also using LLMs to tackle the maintenance work of our personal lives. The more we used them, the more obvious it became that we needed the WorkSquared platform for personal LLM usage. #### Containers for work The first question to tackle was the "container" for the LLM work. There's a technical answer to this question that governs how context is loaded, but more importantly, there's a human question: how do I want to interact with LLMs? Influenced by our time on Next LX and working with Pat Sharpe, we were thinking of the LLMs as "employees", giving them specific tools + prompts (skills didn't become an open standard until December 2025). Should we have only one LLM employee, across all projects? That devolves pretty quickly into a confusing mix of overlapping projects. Should we have one per "project"? One per "life domain"? What does it mean to hire a new LLM employee, to set them up, etc? At the time, Claude.ai had a concept called a "Project" where you could manually add documents and special instructions and Claude would use those across all LLM chats in the Project. We had seen that organization be really helpful. The questions kept coming: do LLMs have access only to the context of their chat plus the project's docs? Can they also search other projects? Do they need to have permission granted explicitly, or are all projects "public", in a sense? Or do we implement some form of message-passing, where LLMs have to ask other LLMs about information within their project domain? While these questions have repercussions for the technical implementation, if you squint, you'll notice these are actually questions about _organizational design._ Companies run into these problems, and each company culture encodes a different answer to "How do we share context across employees on different projects?" We ended up deciding to divide work in LifeBuild into 8 different domains. Projects were containers for specific, bounded work and were assigned to one of the domains. For example, "clean out the garage" might be a project under the "home" domain. For each domain, there was a single, named LLM with full context across those projects and some special instructions for dealing with that domain. For each project, there was a single, unnamed LLM "worker" with a single, long-lived session. I'm not sure if this was the right answer, but it gave some opinionated structure to the system and built a habit for "here is where I go to talk about the garage work" and "here is where I go to talk about finances." #### The Map Eight different domains. Each with some number of projects. Each with an LLM "employee" working for you. When LifeBuild is really humming, there's a lot to keep track of. The accepted dogma for how to organize this today is folders and chats in a sidebar. A folder is a project, with multiple chats, and perhaps some notion of shared "memory" across them. We wanted something better, something spatial, something embodied. We eventually settled on a map similar to an real-time strategy game. Crucially, we decided you should build the map yourself, just like you would in StarCraft or any other RTS. Projects become buildings on the map. At first, we toyed with the idea of "zoning" the map by life area, but we ended up allowing people to place things as they choose and use colors and building styles to represent the different life domains: green for finance, orange for home, etc. We ended up recycling the map concept in nearly every project after LifeBuild. Once you see how powerful a map could be in spatially organizing work, it's difficult to go back to our existing tools with their folder-driven hierarchies. #### Systems versus Projects Another LifeBuild innovation emerged as we wrestled with the idea of a "Project." A reasonable definition is a group of related work with a specific purpose that has a definite endpoint. Projects well-captures some of the work of our lives: sell the camper, plan a trip, move to a new house. But another type of work, one that is perhaps more important, is the habitual work that has no definite endpoint: maintain the yard, keep the cars running, exercise regularly. Establishing rhythms around the ordinary work of maintaining a life is incredibly valuable, and LLMs can be helpful with this. But this work is not a project. And its not merely a recurring event on our calendar. What is it? We settled on the term "system." A system is an interrelated set of work that keeps on working. Like a little engine, the system monitors the world, reports on status, and churns out tasks when appropriate. When a system is running well, the work that needs to be done just gets done, almost without conscious thought. When a system needs attention, it can alert you to the extra-ordinary work that needs to be done. Completing a project is valuable to get things off of our plate, but setting up systems in our life pays us back with additional capacity. Rather than tracking projects to completion, creating new tasks and projects every time an area of our life needs that regular maintenance, the system asks of us only what is needed, right when it is needed. #### The Book Software is not neutral. Software encodes specific workflows, which influence what is done in the world, towards a specific end. To what end does LifeBuild move people? We took a lot of care with the life philosophy behind LifeBuild, what problem it was trying to solve for people (we call them "directors"), and what kind of life the solution would lead to. We came to realize that we had a lot to say on the topic. As we tried to understand how to guide LifeBuild's directors towards the better life, we found ourselves inventing terminology to help explain and guide. And so we turned all of that into a book: [The Sovereignty Gap](). The book is unfinished, but several concepts from the book made their way into LifeBuild, but also into Danvers and my daily conversation: Gold/Silver/Bronze work, Blue/Red/Gray time, projects versus systems. Building LifeBuild truly changed the way we live our lives. ### The Context Library of Alexandria: October 2025 Since we started SocioTechnica, we leaned heavily on LLMs to assist with everything from product planning to technical architecture to actually writing the software. As the tools got more powerful, we were able to do more and more. However, we found that we often had to re-explain certain elements of our thinking, or point to this document or that conversation transcript in order to get decent work. "Setting up the chat" with the right context became quite the drag, and Danvers started wondering if there were a better way. After diving into the research on how other organizations maintain and update knowledge and trying out a few things, we landed on a "context library" that took the form of a set of wiki-linked markdown documents with a few specific LLM employees who would maintain it over time. This context library initially lived inside of LifeBuild's code repository. We were continually surprised by the high-quality conversations and work that we could get simply by starting a new LLM chat backed by the context library. As we browsed the context library itself, we started to understand our own product better than we ever had before. It became central to our own conversations about product features, plans, trade-offs. The context was ostensibly for the agents, but it was also a sense-making tool for us as a team. ### Software Factories: January-March 2026 Software factories - exciting time as agents kept getting better and harnesses and techniques - ralph loops, etc - trading screenshots with friends - huge amounts of work getting done by indie software developers - starting to coalesce on techniques that make LLMs more effective: - guardrails and feedback like e2e testing, linting, unit tests, etc - plans and critique of plans - human-decided technical architecture answering key questions - LLM verification of the implementation - Started to look like a factory line - Stations that the work must go through - the SDLC reimagined with LLMs as primary and humans in the right spots - could oversee much more work - get human help at the right time - Software factory! - I started trying to build one - hand-rolled - Chip - symphony-ts, based off of OpenAI's symphony - A factory plus a library... February 27 was the first overnight run. Four parallel agents worked for 12 hours. ### The Alexandrian OS: March 2026 - July 2026 In February of 2026, we had been working on LifeBuild for about six months. During that time, the world had changed. Models got dramatically better. Harnesses and agent architecture matured. We had a working software factory. And we had a context library that was delightful and effective to work with. We were faced with a decision. Down one road, we continue working on LifeBuild, our quirky little lifestyle-business-shaped personal productivity tool. The other road that was opening before us was much more speculative, but also much larger: combine the context library with a software factory and build a new foundational layer for companies to operate on. It was a tough choice. Ultimately, we chose innovation over commercialization. The opportunity of combining a Library and a Factory and inventing the operating layer for a new type of company, one where humans and LLMs worked collaboratively was too exciting to refuse. We named this vision Alexandria, the shining city. We've already described Alexandria's Library. We were able to extract the library from LifeBuild without too much trouble. But a Library alone does not make a city. More was needed. #### Ledger - The Library is about concepts and their relationship - Each entry has some information about the concepts past and future in addition to its present state - We needed a data structure that carried the timeline of the company in a way that was shared across LLMs and humans - Danvers discovered a common coordination layer used by Navy fleets and Mission Control: the Ledger - The ledger is similar to an event stream, but more selective. Agents can write to it and read from it. It's not for message passing. It's recording events that are relevant to the organization. - A ledger entry may actually result in updates to the Library, but that's a side effect, not the purpose of the entry - I still see this as a "missing primitive" in most agentic environments - There are session logs from the LLM sessions, but those are usually isolated and far too detailed - Each session might produce outputs that can be timestamped #### Factory (skills) - Our last factory before starting Alexandria was Symphony - Workflows over prompts - Guarantee that the LLM follows the ### SkillMaker Studio: A Coda Just the skills, please ## Lessons Learned ### The scale of AI-powered work will break everything When we started working on Next LX two years ago, we were attempting to simulate an entire company. At first, the "work" that the LLMs were doing was entirely a simulation. Work -> a company per learner -> hundreds of AIs working -> modeling other companies to get relationships between companies Each scenario needs multiple companies full of AIs to train... Modern SaaS systems aren't built for this - how do you sign up 1,000 new LLM employees for a new company in minutes? Once we started working with LLMs, even via simulation, we realized that they could do useful work, and thus Pat Sharpe was born. Once we had Pat, we quickly realized that to scale up our Pat's, we needed a new type of interface to oversee the 1-to-100-or-more ratio of humans to AI labor. Thus, WorkSquared. As we explored those new interfaces, LLMs still weren't quite ready to become agents: models weren't good enough, we didn't understand the architecture, some standards needed to emerge. But they were very effective within the scale of one's personal life. So we started working on LifeBuild to give a visualization and management layer to the LLMs acting as "household employees." As we worked on LifeBuild, LLMs got better to the point where we could see an entire company running with significant LLM labor, which gave birth to Alexandria, an operating plane to manage the LLMs working within the company. Suffice to say, we've been working with LLMs as a "country of geniuses in a datacenter" for two years now. And every _company_ can now have a _country_ of LLMs working for it. When you start from that perspective, you start to picture workforce expansion really differently. People don't fully grok how much work is going to be done by AI. During the industrial revolution, we started using machines for things. We used a few machines here and there and soon machines in the workplace far outnumbered humans. And we had to invent new ways of managing, maintaining, and scaling up machine-based work. Similarly, AI labor is going to break all our current systems for what we loosely call "knowledge work" because those systems are based on assumptions around human latency and human scale. Companies may have a 10:1 or 100:1 or 1000:1 ratio of LLMs to humans. We don't even have words for managing this scale of work. And we certainly don't have the tools. ### Human work will continue to be essential People don't yet know what are the intrinsically human functions, and how to organize the organization around the intrinsically human jobs. we discovered in the software process is AI is incredible at printing software when the software that needed to be printed was well understood, but it was already well-defined, not even well-understood. But what really was challenging is that the design AI doesn't decrease the amount of time it takes to do, not by the same order of magnitude or orders of magnitude, doesn't decrease the amount of time that it takes to do the design work and the design work requires deep human understanding. And that deep human understanding just takes time and it can't be fast forwarded and especially if that human understanding needs to be coordinated across a team then that coordination time that human that sort of distributed human understanding the sense making the theory building type stuff that theory building work takes time and it can't be it can't be compressed. There are attributes of every work process that require humans to be involved, but there's no "dark factory" way of doing it. You have to have humans do their part and we don't fully understand what that part is times. In the software world, the process of "designing the software", figuring out what the program should be and whether it meets the needs of the user, is still a uniquely human and human-scale operation. The Alexandrian or Brooksian definition of the design of software is is part of what has to be figured out and understood. ## The Parting Shot SocioTechnica was always about "socio" or "humanity" and "technica" or "technology" and that _partnership_ between humans and machines is what drives humanity forward. "Socio" comes first in SocioTechnica because "Socio" is the motivation: it's who we are designing for. These past two years, we have endeavored to create humane AI systems that put humans in the driver's seat while giving them the coordination tools that they needed to work with AI. SocioTechnica, as a series of explorations, was enormously fruitful. And I'm grateful that Danvers and I were able to take the time to explore. I'm grateful to have had such an incredible partner in that exploration. But there remains much work to be done at this pivotal time when we're adapting to a radical new technology that will reshape work around the globe. Of course, I see this through the lens of a tool-maker. Our existing tools are insufficient, and we need new tools to manage. Work is an essential aspect of our humanity. It gives dignity and purpose and joy. SocioTechnica has definitely given me that! ...carry forward into the future.