Sentient: a self-hostable personal assistant that reads your mail and runs background tasks

The problem Sentient targets: one assistant instead of a pile of scripts

Most personal automation ends up as a folder of cron jobs, a chat window, and a notes file. Sentient's pitch is to collapse that into one application. The README frames it as a central command center that bridges goals and the actions required to achieve them, and describes a proactive partner that manages your digital life without long prompts. That is the claim to evaluate, not the feature list.

The intended user is someone who already runs services on their own hardware and wants an assistant that remembers context across sessions. The README lists text chat, voice chat, learned preferences and habits, multi-step and recurring task execution, and reading email and calendar to suggest schedules. It also states the platform can be self-hosted and configured to run fully locally, which is the sentence that matters most for anyone with data they will not put in someone else's database.

There is a second audience implied by the topics list: people interested in agents, memory and MCP. If you are evaluating agent architectures rather than looking for a daily driver, the repository is a working application to read, not a framework to import.

What the repository actually contains: an application, not a library

The primary language is Python, and the README shows screenshots of a web interface with pages for chat, voice, tasks and integrations. That combination points to a server plus a browser client rather than a CLI tool. The repository layout is not included in the material supplied, so the exact module structure, entry point and dependency manifest cannot be confirmed here.

The feature set visible in the README is broader than most assistant projects: text chat, voice chat, a Tasks page for recurring, triggered, scheduled and swarm tasks, a memory system that learns facts about the user and reuses them to personalize actions and responses, and connectors for over 20 apps. MCP appears in the repository topics, which suggests the Model Context Protocol is part of how tools are exposed, but the README does not describe the integration mechanism, so treat that as a topic tag rather than a documented architecture.

The honest summary is that Sentient is positioned as a product with a UI, not as a component. Anyone hoping to pip install a memory layer and call it from their own code is looking at the wrong artifact.

Memory, tasks and connectors: the three moving parts

The memory feature is described as learning memories about you and using them to personalize actions and responses. What the README does not say is where those memories are stored, how they are retrieved, or whether they can be inspected and deleted. For a system that reads email and calendar, the absence of that detail in the README is the first thing a privacy-conscious operator should chase down in the docs.

The task system is the more concrete piece. The Tasks page supports recurring, triggered, scheduled and swarm tasks. Recurring and scheduled are familiar categories. Triggered implies event-driven execution, though the README does not name the trigger sources. Swarm implies multiple agents or workers cooperating on one job, again without a documented mechanism. These four labels are the project's own, and they are the clearest signal of intended scope.

Connectors are listed only as a count: 20+ apps supported. No names, no authentication model, no scopes. That is a real gap. Whether your calendar provider or mail host is among the 20+ is something you have to check in the GitBook docs or the running app, not in the README.

Getting it running: the README points away from itself

This is the weakest part of the repository for a self-hoster. The Getting Started section says only: to access Sentient, head over to our website. The self-hosting section says the platform is open-source and can be self-hosted and configured to run fully locally, then links to a GitBook page titled running-sentient-from-source-self-host.

No install command, no Python version, no environment variable names, no database requirement and no model provider configuration appear in the README itself. If you are deciding whether to adopt Sentient, that means your first step is the GitBook page, not the repository. Everything about the setup path has to be verified there.

The two paths are therefore a hosted service at sentient.existence.technology and a source deployment. The README presents the hosted route as the default and self-hosting as the alternative. For an AGPL project that markets privacy and local operation, leading with the hosted option is a deliberate ordering choice, and it is worth noticing.

The licence is AGPL, and the README's licence field disagrees with its own text

The GitHub metadata reports the licence as NOASSERTION, meaning the platform could not classify it automatically. The README is explicit: distributed under the GNU AGPL License, with details in LICENSE.txt. When metadata and README conflict, the LICENSE.txt file in the repository is the document that governs, and it is the first file to open before you plan a deployment.

AGPL matters specifically because Sentient is a network service. If you modify the code and let other people interact with it over a network, the AGPL's source-availability condition is generally understood to apply to those users. A private single-user instance on your own machine is a different situation from a modified instance you expose to a team or to customers. This is not legal advice, and the boundary depends on your jurisdiction and your deployment; if you plan to modify and host Sentient for others, get the licence reviewed rather than assuming.

The practical consequence for a company is narrower than it looks. Running Sentient unmodified for yourself is one thing. Forking the memory system into a proprietary product, or shipping a modified hosted version, is where the AGPL becomes a business decision rather than a footnote.

Where Sentient is the wrong tool

Three cases stand out. First, if you need a stable, versioned dependency with a documented API, Sentient is an application with no releases retrieved in the material supplied, so there is no release history to pin against. You would be tracking the master branch.

Second, if you cannot tolerate an assistant reading your email and calendar, the proactive scheduling feature is the core of the product, not an add-on. Turning it off removes a large part of what Sentient does. The README does not document a permission model for connectors, so you cannot tell from the README how narrowly you can scope access.

Third, if you want a memory component rather than an assistant, the comparison is with something like Mem0, which is designed as a memory layer you call from your own application. Sentient bundles memory with chat, voice, tasks and connectors and expects to be the thing the user talks to. Mem0 expects your code to be the thing the user talks to. The difference is not quality; it is where the control flow lives. Choosing Sentient means adopting its UI and its task scheduler along with its memory.

Maintenance and upgrade cost

The last push recorded is 2026-04-13, and the repository is not archived, so the project is active at the time of writing. There are no retrieved releases, which means there is no tagged version to upgrade between. Self-hosters should expect to pull from master and read commits, or to pin a commit hash and manage divergence themselves.

There is no changelog in the material, no migration notes, and no statement about data format stability for the memory store. If memories are persisted in a format that changes between commits, an upgrade could require a migration the project has not documented. That risk is unquantified here, but it is the concrete thing to ask about before storing months of personal context in the system.

The connector count is another maintenance surface. Integrations against external APIs break when those APIs change, and with 20+ connectors there is a standing maintenance load that falls on the project and, if you self-host a fork, on you. The README gives no compatibility policy for connectors.

Editorial conclusion

Adopt Sentient if you want a single AGPL codebase for a personal assistant with memory, voice, and scheduled or triggered background tasks, and you are willing to read the GitBook self-host page rather than the README for setup. Do not adopt it if you need a documented Python version and dependency list before you commit, if you cannot accept AGPL obligations on a modified deployment, or if you want a narrow library to embed rather than a full application with a web UI. Before you start, open the self-host docs and confirm the exact run commands, the model or API provider configuration, and which of the 20+ connectors you actually need, because the README names none of them.

Official sources

1. existence-master/Sentient on GitHub
2. Issues
3. Project website
4. README