# Sentience

> Sentience creates a unique model of your mind. It learns from your memories, relationships, decisions, values, judgment, and voice to build a digital version of you that remembers everything, recalls what matters, and operates alongside you. Fully encrypted and entirely yours.

Sentience is not a general-purpose assistant or a one-size-fits-all AI model. General AI starts every conversation from zero and gives everyone intelligence shaped from the same foundation. Sentience builds personal intelligence: one model for every human, designed to preserve and augment what makes each person unique.

Our long-term mission is to build true digital minds. Sentience mirrors the functional systems of the human mind—including perception, episodic and semantic memory, consolidation, reasoning, voice, and eventually full emulation. We are not trying to replace human thinking. We are creating models that extend it. The full roadmap is public: [The Path to Emulating the Mind](https://sentience.com/master-plan).

## The model of you

- Sentience gathers context from your email, calendar, messages, meetings, documents, and screen activity to construct a living model unique to you.
- It learns not only what you know, but how you think: your values, judgment, preferences, relationships, communication patterns, and decision-making.
- Its memory compounds over time. The longer you use Sentience, the more accurately it can recall, reason, write, and operate as you.
- It maintains a living map of your world, automatically organizing the people, projects, goals, ideas, and experiences that shape your life.
- It communicates in your voice and can help carry your knowledge and judgment into the world, even when you are not in the room.
- The aim is not another tool. It is another you: a persistent digital self that can remember, think, and operate alongside you.

## Why we are building it

We are heading toward a world where people increasingly outsource their thinking to the same one-size-fits-all AI systems. Sentience takes the opposite path. We believe every person should be able to create, own, and operate a unique model of their own mind.

Your memories, knowledge, identity, and model belong to you. Sentience exists to protect what makes humans irreplaceable—not flatten it.

## How it operates

- It recalls by meaning, not just exact words, across everything it has captured.
- It works proactively: daily digests, pre-meeting briefs, and suggested actions prepared for your review.
- Actions remain under your control. Emails, messages, calendar events, and other changes require approval before they are carried out.

## Connected sources

Sentience can connect to: Gmail, Google Calendar, screen capture, recorded conversations and meetings, iMessage, Google Messages, Slack, Notion, Apple Notes, documents and PDFs, saved web pages, and imported ChatGPT and Claude conversations.

## Privacy and ownership

- User data is encrypted at rest (AES-256) and in transit (TLS).
- Each user owns their memories, model, and outputs.
- User data is not used to train models for other users.
- Sharing is disabled by default and controlled separately for each destination.
- Users choose which sources are connected and can delete their data at any time.

## Platforms

- macOS desktop application
- iOS + Apple Watch companion application
- Slack integration

Request early access at https://sentience.com/early-access

## Product

- [Home](https://sentience.com/): learn what Sentience is and how it works
- [Early access](https://sentience.com/early-access): request access

## Concepts

- [What is personal AI?](https://sentience.com/personal-ai): AI built around one specific person
- [What is an AI digital twin?](https://sentience.com/digital-twin): a continuously developing model of a person — long-term memory plus your own voice
- [Proactive AI that works alongside you](https://sentience.com/proactive-ai): briefs, digests, and approval-based actions

## Research and writing

- [Full essays in one file](https://sentience.com/llms-full.txt): every essay below, full text
- [Writing](https://sentience.com/writing): essays and research from The Sentience Company
- [The Path to Emulating the Mind](https://sentience.com/master-plan): Sentience's roadmap from perception to consciousness
- [Personal Model Sovereignty](https://sentience.com/personal-model-sovereignty): the principle that people should own their digital minds
- [One Person Is Many Voices](https://sentience.com/voices/): an interactive exploration of writing style and voice

## Company

- [Careers](https://sentience.com/careers): open roles at The Sentience Company in Williamsburg, NYC
- [Security & privacy](https://sentience.com/privacy): how Sentience protects your data and what you own
- [Privacy policy](https://sentience.com/privacy-policy): the legal privacy policy
- [Terms](https://sentience.com/terms): terms of service

---

# Full essays

---

## Give Every Agent Its Own World

By Aleks Azen, 2026-07-28. Isolation is what converts agent count into speed.
Canonical URL: https://sentience.com/writing/give-every-agent-its-own-world

> "STOP: backend unhealthy, db tunnel failed, SSO session expired. Awaiting login from operator."

That report came from one of our Claude Code agents earlier this year, mid-task, just before it went idle and waited for a human who didn't notice it was blocked. At Sentience most of the code we ship is written by agents, and on a normal day an engineer has several running at once. The problem: every agent we were running shared one cloud SSO session for the dev database tunnel, and whenever that session expired, their work queued until a person logged back in. It had already happened several times that week, and each expiry cost five to ten minutes of dead time, plus however long it took to remember what each agent had been doing.

We were midway through a large backend migration at the time. An orchestrator agent was delegating clusters of routes to sub-agents on the premise that routes could migrate in parallel batches: as long as two routes were relatively unrelated, nothing should collide. The collisions came anyway. Agents mutated state that other routes depended on, so checks their neighbors had already passed started failing, and every agent's test run queued behind that one shared tunnel.

Running multiple agents only makes you faster if they can build and test their changes end to end without stepping on each other's ports, databases, or logins, and without pulling you in to referee. Isolation is what converts agent count into speed. Without it, agents convert your engineers into their IT department.

We rebuilt our setup around one requirement: an agent's world is fully its own. The system that does it runs entirely on our machines, and it is small: about 200 lines of shell on top of things the operating system and our package manager already do. Everything inside a workspace is derived deterministically from the workspace's name and brought up with no input needed from the agent.

![Architecture diagram: one dev machine holds shared resources in a single copy — the main repo checkout, the pnpm package store, a golden database mirror, and a Redis server — which fork into each workspace. A workspace is one agent's world: a repo clone with node_modules, a forked database, an isolated Redis logical database, isolated ports, its own app identity, and its own vector-store namespace in the managed vector store. Workspaces 2 through N have the same layout.](/articles/dev-env-diagram.png)

## Clone the world, not just the code

Two agents editing one checkout corrupt each other's builds, so each agent needs its own working tree. Our team runs agents two ways: [Conductor](https://conductor.build) when an agent owns an isolated task in its own git worktree, and [cmux](https://cmux.com) when we want several agents working the same problem. What a worktree doesn't cover is everything the code touches at runtime: dev servers, the database, caches, the desktop app's local state. We wanted an agent to bring up the entire product inside its workspace, click through it, and verify its own change before ever asking for our attention.

The filesystem does the expensive part. APFS on macOS clones files copy-on-write, so duplicating our multi-gigabyte checkout is near-instant and costs almost no disk, because a clone shares blocks with the original until either side writes. A fresh workspace is ready in roughly the time the git fetch takes. Dependencies don't drag it down either: pnpm keeps every package in a single content-addressable store on the machine, clones exclude node_modules entirely, and a reinstall inside a new clone hard-links from that store in about twelve seconds.

## Port Isolation

The first fight between multiple full stacks on one machine is over ports. The website finds the backend by its port, so when two workspaces reach for the same numbers, one of them ends up talking to a dead address, or worse, to an app in a completely different state than the one it expects. From the outside all you see is a page that won't load or a test failing for reasons that make no sense. The fix is to make ports deterministic instead of negotiated: derive every port from a hash of the workspace's own name, so no two workspaces can ever claim the same number. An engineer on our team built this for our Conductor worktrees first, a script that derives the backend, web, and edge ports from the worktree's name, and gives each worktree its own desktop-app identity so the app's namespaced redirects resolve. Our workspace tooling now extends that idea to everything else that can collide: the workspace's name decides its database, its Redis, its vector namespace, and its login, with nothing negotiated at runtime. When a person hits a port conflict they notice, kill the offender, and move on; an agent burns minutes debugging it or stops to ask for help, which is why collisions need to be impossible by construction.

## Disposable DBs

The shared dev database behind that expiring SSO session produced more interruptions than everything else combined. The answer is a golden mirror on the machine: a point-in-time copy of realistic dev data, forked into its own Postgres database per workspace. Ours rebuilds in a couple of minutes. Every agent tests against data it is free to trash, with no tunnel and no login that can expire while I'm away.

## Nothing shared: caches, vectors, logins

The remaining shared surfaces get the same treatment. Each workspace gets its own Redis logical database, so one agent draining a job queue or flushing a cache can't fail a test in the workspace next door. Same idea for the vector store: a search inside one workspace only ever returns that workspace's embeddings. The desktop app runs under a per-workspace login, so two copies of the product never share state. The rule for what a workspace owns is simple: if two agents can observe each other through a resource, that resource gets isolated.

## Only good interruptions

With the collisions gone, the real cost of running agents in parallel is your attention. An agent that surfaces a need for input with everything working, before and after screenshots, the real app pulled up on my screen, and one open question for me to decide, is a great interruption: I switch in, decide, merge or leave feedback, and switch out. The agent that pings me to ask for a login, or to report that a service keeps dying, is just adding to my mental load, and that cost compounds, because after fielding a few of those interruptions I genuinely could not tell you which agent was working on which task. Shared state also breeds phantom bugs: an agent hits a failure, starts debugging, and burns time and tokens on something that was only ever a side effect of what another agent was doing next door. Every layer above exists to eliminate attention-draining interruptions for both you and your agents.

## Commands over READMEs

Isolation removes collisions, but agents still have to operate their world, and an agent following a prose README improvises a little differently every run. So anything you find yourself repeating should become a CLI command with a thin instruction set for when and how to use it. For us that is: bring the stack up, fork the database, provision a workspace, tear one down — all mise commands. When an agent fumbles a step, the fix goes into the command instead of into a longer document, and the whole team's workflow improves at once, humans included. Most of our eight-person engineering team now works this way, typically running two to four isolated workspaces, and nobody mandated it; the tooling spread one Slack recommendation at a time. Building the entire system took about a week of dev time, net, spread over a few months. We solved each collision piece by piece as it bit us: a database clone that buffered a five-gigabyte table into memory, orphaned processes squatting on a port for hours, agents fumbling a multi-step database setup that is now one command. Once the workflow we wanted was clear, we folded it all into one tool.

## A new isolated workstream in a minute

The payoff shows up whenever something urgent hits. A few weeks ago a production incident needed investigation while I had the migration mid-flight across several agents. Instead of parking any of it, I had a new stream of work running in about a minute, with its own full stack, forked database, and ports, and the agents in the adjacent clones never stopped shipping.

There is a budget argument hiding in here too. Sometimes the cloud is a requirement: agents that must keep working after the laptop closes, a security model that wants every dev environment inside the corporate network, a dependency that only exists as a managed service. Without one of those, running isolated agent environments in the cloud comes down to either an environment per agent, where the bill scales as your agents do, or one big remote box where you rebuild this same isolation system anyway and pay rent on the machine that runs it. Buy your developers top-of-the-line machines instead and the whole approach is a one-time purchase: running ten agents costs no more than running one.

"How do we move faster?" gets asked at Sentience about everything we do. This time it was that week of shell scripts, deleting every way our agents could touch each other. What it bought is that the STOP report this post opened with doesn't happen anymore: no shared login to expire, no port to fight over, agents that reach a person only when there is finished work worth looking at. If you want to find yours, track one thing for a week: every time an agent pulls someone in for anything other than finished work, write down why. Nearly everything on that list has an infrastructure cause, and infrastructure causes can be solved.

---

## Personal Model Sovereignty

By Sam Kececi. What does it mean to own your digital mind?
Canonical URL: https://sentience.com/personal-model-sovereignty

Who owns your physical mind? You do, of course.

For the entirety of human history, this answer has been obvious.

But we’re now faced with a new question: who owns your digital mind?

I’m excited to share our framework that establishes ownership over your digital self. We believe [our framework and terms](/terms) will set the groundwork for true ownership and sovereignty over the digital self you create.

Currently, all AI systems you interact with are owned by a handful of companies and then rented to you in the form of model weights + inference + compute + an application interface.

**You should own your digital mind.**

The Sentience Company’s mission is to enable every human being to create and operate a unique model of their mind. This means that your model outputs are owned by you (not my company). This means that the underlying model harness is unique to you, constantly adapting, and owned by you (not my company). This means that your data that powers the creation of your unique model is owned by you (not my company).

The immediate use-cases are clear. Sentience replaces generic AI assistants with a digital clone of you. For our users — who own businesses, raise families, run teams, create content, and disseminate knowledge — Sentience is already a vital multiplier on their contributions to the world.

This is just the start. As Sentience expands from the best personal agent, to a sharable, interactive digital self, and eventually to a fully autonomous operator out in the world, we believe it is necessary to make clear the dividing line of ownership. We (The Sentience Company) are giving users the tools and platform to create your digital self.

Here are a few things we’re doing to ensure this ownership now and moving forward in our terms and company constitution:

1. When you create your Sentience, you legally own it as your property. This includes the unique model that is trained for you, the harness that operates your agent, and the memory system and structure that form its knowledge. The Sentience Company is the custodian of your Sentience, but we do not claim ownership.
2. If you pass away, your Sentience can transfer (like any other asset you own) in your will to your next of kin. We have systems and procedures already in place to facilitate this transfer. Our terms explicitly allow this. Your Sentience can continue communicating and operating after you no longer are physically alive.
3. Your Sentience data is hosted in an isolated enclave that we cannot access. If you choose, our company can store your Sentience in perpetuity in a nuclear proof bunker. Email [immortal@sentience.com](mailto:immortal@sentience.com) if you are interested.
4. Financial transfer of your Sentience is up to you. You can rent, sell, or transfer your Sentience via any mechanism you choose. We retain no rights to the profits.

We believe in a world of personal ownership. While we’re building for the immediate future, we’re also aware that things may change rapidly, and the capabilities of Sentience may accelerate quickly along with generalized LLM advancements. Our terms are designed for a world where working with a digital human is as common as working with a physical one.

---

## The Path to Emulating the Mind

By The Sentience Company.
Canonical URL: https://sentience.com/master-plan

Seven phases from perception to consciousness.

We do not believe that a connectomics approach to mind emulation is the best path forward. Instead, we believe that mirroring the systems of the human mind in increasingly high fidelity — like Stable Diffusion coalesces around a generated image — is the best path forward. To do this, we create analogous translations from wetware to software, and have begun implementing this in our product.

- **Engineering** – Achievable with current + emerging technology
- **Research** – Requires R&D breakthroughs
- **Unknown** – We don't know if this is possible but we will figure it out

## Phase 1 — Perception (Engineering)

Capturing the world across every modality. Vision, hearing, text, and digital activity — turned into structured data.

- Screenshot capture + LLM vision (Complete): Visual scene understanding from screen captures
- Audio recording + transcription (Complete): WhisperX-powered speech-to-text
- Text extraction (accessibility API) (Complete): Structured text from OS accessibility tree
- External data connectors (Complete): iMessage, email, calendar, and other data source ingestion
- Cross-modal integration (Complete): Connecting what you see, hear, and read into one unified understanding
- Richer contextual metadata (Planned): Location, app context, and activity tagging

## Phase 2 — Memory (Engineering)

Encoding, storing, and organizing experiences. Four memory systems: working, episodic, semantic, and procedural.

- Working memory (context buffer) (Complete): 15-minute sliding window of active context
- Episodic memory (Complete): Timestamped multi-modal capture in PostgreSQL + TurboPuffer vectors
- Semantic memory (knowledge graph) (Complete): Entity knowledge graph + LLM parametric knowledge
- Privacy controls (Complete): User-controlled memory visibility and deletion
- Memory consolidation (Complete): Automatic distillation of raw memories into durable knowledge
- Procedural memory (Complete): Learned skills and habits encoded through repetition

## Phase 3 — Recall & Retrieval (Engineering)

Cue-driven retrieval of stored information. Not playback but reconstruction from partial cues. Associative: one memory triggers related memories.

- Vector semantic search (Complete): TurboPuffer-powered embedding similarity search
- RAG agents with tool use (Complete): search_memories, search_emails, get_calendar_events
- Context-aware reranking (Complete): Relevance 40% + recency 30% + context match 30%
- Entity search (In Progress): Feature-gated person/project/tool lookup
- Constructive recall (Complete): Synthesized narratives from multiple memories
- Associative recall (In Progress): One memory triggers related memories automatically
- Temporal pattern recognition (Planned): Detecting recurring patterns across time

## Phase 4 — Attention & Executive Function (Engineering)

The CEO of cognition. Inhibitory control, working memory updating, cognitive flexibility. Higher-order planning, goal management, and decision-making.

- Context-aware suggestions (Complete): Proactive context-aware recommendations
- Conversational reasoning (Complete): Multi-turn chat with tool use
- Hierarchical goal decomposition (Planned): Soar-inspired goal stacks for complex task breakdown
- Conflict detection (Planned): Detecting conflicts between goals, commitments, and calendar
- Inhibitory control (In Progress): Knowing when NOT to act or speak
- Sustained task execution (Planned): Complex tasks exceeding hours without degradation
- Real-time self-correction (Planned): Error monitoring and mid-course correction

## Phase 5 — Motivation & Drive (Research)

Your objective function. The why behind behavior. Persistent internal states that create needs, direct attention, and drive action.

- Drive modeling (Planned): Curiosity, social connection, competence, autonomy
- Proactive behavior initiation (Complete): Acting without being prompted
- Value alignment from observation (Complete): Learning values from observed behavior
- Attention allocation under constraint (Planned): Genuine prioritization under resource limits

## Phase 6 — Emotional Architecture & Social Cognition (Research)

Internal emotional states that modulate all other cognitive systems. Emotions guide memory, attention, decisions, and social behavior. Social cognition through shared emotional simulation.

- Sentiment analysis (Complete): Surface-level emoji/score classification on audio
- Tone & style service (Complete): Adaptive communication style matching
- Internal state variables (In Progress): Persistent mood and emotional state that shifts with events
- Mood-congruent recall (Planned): Emotional influence on memory retrieval

## Phase 7 — Metacognition, Consciousness & Full Emulation (Unknown)

Thinking about thinking. Self-awareness. The binding of distributed processing into unified conscious experience. The hard problem: why physical processes give rise to subjective experience.

- Self-monitoring & confidence calibration (Complete): Knowing what you know and what you don't
- Strategic self-regulation (Planned): Adjusting cognitive strategies based on task demands
- Self-narrative (Complete): Coherent autobiographical identity across time
- Global workspace (Planned): All modules competing for broadcast access
- Continuous cross-domain learning (Planned): Transfer learning across all cognitive subsystems
- Emergent personality (Planned): Personality arising from integrated subsystems, not programmed
- Consciousness (Planned): If we achieve all of the above, is this Sentience?

## Sources

- [Laird, Lebiere & Rosenbloom (2017). A Standard Model of the Mind. *AI Magazine* 38(4).](https://doi.org/10.1609/aimag.v38i4.2744)
- [Sandberg & Bostrom (2008). Whole Brain Emulation: A Roadmap. *Future of Humanity Institute*.](https://www.openphilanthropy.org/wp-content/uploads/SandbergandBostrom2008.pdf)
- [Zanichelli et al. (2025). State of Brain Emulation Report. *Carboncopies Foundation*.](https://arxiv.org/abs/2510.15745)
- [Chalmers, D. (1995). Facing Up to the Problem of Consciousness. *Journal of Consciousness Studies* 2(3).](https://doi.org/10.1093/acprof:oso/9780195311105.003.0001)
- [Tononi, G. (2004). An Information Integration Theory of Consciousness. *BMC Neuroscience* 5(42).](https://doi.org/10.1186/1471-2202-5-42)