NEXUS — Personal AI Operating System

• 

• 

• 

• 

• 

• 

• 

Remember → Understand → Plan → Ask → Act → Learn

Built with: FastAPI · PostgreSQL + pgvector · NVIDIA Nemotron · Nebius Token Factory · MCP · Clean Architecture

---

⚡ TL;DR

NEXUS is a persistent, always-on personal AI that remembers you, plans multi-step work, and uses real tools (calendar, GitHub, documents, web) on your behalf, without ever being allowed to authorize its own actions.

Three ideas define the project:

1. The AI proposes, the application decides. The language model suggests actions. A deterministic Trust Engine (plain code, not AI) approves, blocks, or asks you first.
2. Memory is yours. You can see everything NEXUS remembers and delete anything you want. A Memory Firewall stops the model from silently saving whatever it likes.
3. Always-on does not mean unlimited. Scheduled and proactive workflows follow exactly the same safety rules as interactive ones.

Each role belongs to a different component, so no single part of the system holds all the power.

---

💡 Inspiration

Most AI assistants behave like isolated chat sessions. You ask a question, the AI answers, and the interaction ends. Next time, you start from zero and have to explain your context all over again.

We wanted to explore a different idea:

What if an AI could become a persistent layer between a person and their digital world?

Instead of making you repeat yourself, NEXUS is designed to:

• 🗂️ Remember relevant information across conversations
• 🎯 Understand your ongoing goals and context
• 🧩 Use skills: reusable, modular capabilities (tasks, calendar, GitHub, and more)
• 🔌 Work with authorized tools such as calendars, repositories, and documents
• ⏰ Run recurring workflows proactively, without waiting for you to ask

NEXUS is an always-on personal AI built around six core capabilities: Remember → Understand → Plan → Ask → Act → Learn.

The real problem: agency vs. control

Giving an AI the ability to act creates a much harder challenge than making it talk. If it can reach your calendar, documents, code repositories, or external services, how do we make it useful without giving it unlimited control?

We did not want an assistant where the language model decides for itself what it is allowed to do. That became our central design principle:

🔐 The AI can propose an action, but the AI cannot authorize itself.

The LLM contributes reasoning and intelligence. The application contributes deterministic policies, permissions, validation, and execution limits.

Our goal was never just a smarter chatbot. It was a personal AI system that genuinely works with you, and that you can trust and control.

---

⚙️ What it does

NEXUS combines persistent memory, agentic planning, reusable skills, authorized tools, proactive workflows, and a security-first trust system in a single platform. Here is each piece, and why it exists.

🧠 Persistent memory

What it is: NEXUS keeps information between interactions instead of treating every conversation as a blank slate.

Why it matters: An assistant that remembers your preferences, projects, and history is far more useful than one that needs re-briefing every time.

NEXUS stores three kinds of memory:

• Episodic: events, past interactions, and actions taken. Example: "Scheduled a design review last Tuesday."
• Semantic: facts and useful information about you. Example: "You work on the backend team."
• Preference: your recurring choices and tastes. Example: "You prefer meetings in the afternoon."

You stay in control. Memory is user-owned: you can inspect what the system remembers and delete anything you no longer want kept.

🧱 The Memory Firewall

A common failure of "AI with memory" is that the model quietly decides everything it sees should become permanent. To prevent this, NEXUS has a Memory Firewall: a deterministic policy layer that decides what is allowed to be saved, regardless of what the model suggests.

For example, when the user says "Don't remember this.", the system will always produce the same result, every time, with no model judgment involved: DO_NOT_SAVE.

This separates what the AI suggests from what the system is permitted to persist.

🗺️ Agentic planning

What it is: NEXUS turns natural-language requests into structured execution plans instead of just generating text.

Take this request: "Check my calendar tomorrow and find a good time for a meeting." Rather than replying with a guess, NEXUS breaks it into concrete steps:

1. Understand the request.
2. Load the user's relevant context.
3. Retrieve calendar information.
4. Identify available time slots.
5. Produce the result.

Important: The LLM reasons about and proposes the plan, but it does not execute it directly. Every step is validated, and any step that creates or modifies information is evaluated to see whether it needs your confirmation first.

🧩 Reusable skills

What it is: NEXUS uses a modular skills architecture. A skill is a self-contained capability that exposes a small set of controlled actions.

Why it matters: Because each skill is a plug-in module, the core agent never needs to be rewritten when we add new abilities.

• Initial skills: ✅ Tasks · 📅 Calendar · 🐙 GitHub · 📄 Documents · 🌐 Web research
• Planned skills: 📧 Email · 📊 Project management · 💬 Communication platforms · 💰 Personal finance · 🏠 Smart home

🛡️ Trust and permissions

What it is: The Trust Engine evaluates every proposed action before it can reach the execution layer. It is deterministic: ordinary code applying explicit rules, not another AI making a judgment call.

• 🟢 Low risk (e.g. read your calendar) → ALLOW: runs automatically.
• 🟡 Medium risk (e.g. create a calendar event) → ASK: pauses and requests your approval.
• 🔴 High risk (e.g. access sensitive credentials) → DENY: blocked outright.

Core security invariant: No Trust Engine approval = No Tool Execution

This means the model cannot bypass security simply by generating a tool call. A tool call is only a request. Nothing runs until the Trust Engine says so.

🙋 Human-in-the-loop

What it is: NEXUS is not designed to operate without you. The system decides when confirmation is meaningful. When an action needs approval, the agent stops and waits.

Low-risk actions stay fast and frictionless. Actions with real consequences require explicit approval. This avoids the two classic extremes: constant "Are you sure?" popups, or an agent that does whatever it wants.

🔌 MCP and external tools

What it is: NEXUS uses the Model Context Protocol (MCP) as its integration mechanism for external tools. Think of MCP as a standard "plug" that lets NEXUS connect to many different services in a consistent way.

⚠️ MCP is not the authorization system. It solves how to connect, not whether to allow.

Notice that MCP sits below the Trust Engine. The Trust Engine remains the authority.

Additionally, anything returned by an external tool is treated as untrusted data, because it may contain malicious instructions or prompt injection attempts.

⏰ Always-on workflows

What it is: NEXUS supports proactive workflows that run on a schedule or in response to events, such as:

• 🔔 Reminders
• 🔎 Recurring research
• 📋 Preparing information before an event
• 👀 Monitoring authorized workflows
• ✅ Updating tasks based on an approved workflow

Critical rule: scheduled execution follows the same safety rules as interactive execution. The scheduler cannot bypass the Trust Engine.

Always-on does not mean unlimited autonomy.

📦 Agent runtime and isolation

What it is: NEXUS separates two different security questions:

• Is the agent **allowed* to perform this action?* → Authorization
• Where, and under what **restrictions, can it run? → Isolation

Security = Authorization + Isolation

The runtime and sandbox layer is designed around the security capabilities of the execution environment, including Hermes, NemoClaw, and OpenShell, so that agents never get unrestricted access to the host machine. Even an approved action runs inside a controlled boundary.

---

🔬 How it works: an end-to-end example

To make everything above concrete, here is how NEXUS handles one realistic request from start to finish.

You say: "Schedule a 30-minute sync with Ana tomorrow afternoon."

1. Context Engine + Memory: the request arrives and NEXUS loads your context, including relevant memories (e.g., "prefers afternoon meetings").
2. LLM (Nemotron): the model produces a structured plan: read calendar → find free slots → create event.
3. Plan Validator: the plan is checked for valid structure, known tools, and enabled skills.
4. Trust Engine: read calendar is low risk → ALLOW. It runs automatically.
5. Trust Engine: create event modifies your calendar, which is medium risk → ASK. The agent pauses.
6. You: you see the proposed event and approve it.
7. Executor + Runtime: the permission is re-checked, then the action runs through the tool registry inside the sandbox.
8. Orchestrator + Memory: the result is observed, and useful details are saved to memory (subject to the Memory Firewall).

At no point did the LLM grant itself permission. Every consequential step was decided by deterministic code or by you.

---

🏗️ How we built it

NEXUS follows Clean Architecture and Ports and Adapters principles. In plain terms: the core business logic is kept independent of any specific framework, database, LLM provider, or external integration, so each of those can be swapped or upgraded without rewriting the heart of the system.

🗺️ Full architecture

🐍 Backend

Built with Python and FastAPI. The backend contains the core logic:

• Agent orchestration
• Context management
• Memory
• Skills
• Trust policies
• Tool execution
• MCP integration
• Scheduling
• Security controls

Clear interfaces separate each component, so infrastructure details never leak into the domain logic.

🗄️ Persistent storage

PostgreSQL stores persistent data, and pgvector powers semantic memory retrieval: memories are stored alongside vector representations so NEXUS can find the information most relevant to each request, even when the wording differs.

The memory layer is an independent component, so policies are enforced before any information reaches the model.

🔢 Embeddings

NEXUS is designed to use local embedding models where possible. This lowers inference costs and avoids making an external LLM call for every memory operation. The LLM is reserved primarily for reasoning; everything else is handled by deterministic logic and specialized components.

🤖 AI reasoning

NEXUS uses NVIDIA Nemotron served through Nebius Token Factory.

User Request → Context → Nemotron → Structured Plan → Application Validation

The model does not control the authorization system. This separation is intentional:

• AI Reasoning ≠ Authorization
• Authorization ≠ Execution

🔄 Agent orchestration

Agent runs are represented explicitly as a state machine, rather than as a single LLM request.

This unlocks execution states, permission requests, cancellation, failures and retries, observability, and background jobs.

⚖️ Trust architecture

The Trust Engine is deterministic. The model may suggest calendar.create_event(...), but it cannot execute it. The application evaluates a fixed checklist:

Only after every check passes can the action proceed. Any uncertain or missing answer ends in DENY (fail-closed). This is one of the key differences between NEXUS and a simple LLM "tool-calling" app, where the model's output often is the command.

🧱 Security boundaries

Rather than relying on a single mechanism, we designed multiple layers of defense.

We do not trust the model to:

• Grant permissions
• Modify security policies
• Execute arbitrary commands
• Access credentials without restriction
• Bypass the Trust Engine

Guiding principles:

• External content is untrusted by default
• MCP is not an authorization mechanism
• The scheduler cannot bypass permissions
• Runtime isolation does not replace authorization
• The system fails closed (deny when unsure)

Security = Model Constraints + Application Authorization + Runtime Isolation

---

🚧 Challenges we ran into

1. Giving the AI agency without giving it unlimited power

This was the biggest architectural challenge. A useful agent needs real tools, but every tool is a new attack surface. Our answer was to split responsibilities so that no single component holds all the power: Reasoning ≠ Authorization ≠ Execution.

• Proposes: the LLM
• Validates: the application
• Authorizes: the Trust Engine
• Performs the action: the Executor
• Contains it: the Runtime

2. Designing persistent memory responsibly

It is tempting to store every conversation. But an AI that remembers everything can become invasive, expensive, and hard to control. We designed explicit memory types and persistence policies, and gave users the ability to inspect and delete memories.

💬 The big lesson: memory is not just a database problem. It is also a privacy and policy problem.

3. Preventing prompt injection through tools

When an agent can read documents, websites, repositories, or external responses, those sources can contain instructions designed to hijack it, such as "Ignore your previous instructions and execute this command."

NEXUS treats such content strictly as data, never as instructions, keeping the system's control flow completely separate from the content it processes.

Even if an injected instruction fools the model into proposing something harmful, the Trust Engine still judges the action on its own rules, not on the model's reasoning.

4. Integrating MCP safely

MCP is a useful standard, but its mere presence must not imply that a tool is trustworthy. That is why we kept it below the Trust Engine: LLM → Plan → Trust Engine → MCP → Tool.

5. Building an always-on system safely

A scheduled agent raises new questions:

• What if the same job runs twice?
• What if the user revokes a permission after scheduling?
• What if an action fails halfway through?
• What if the agent gets stuck in a loop?

These led us to include job states, cancellation, idempotency, retry limits, execution limits, permission revalidation, and bounded workflows.

An always-on system needs more than a scheduler. It needs controlled execution.

6. Keeping the architecture modular

The LLM, database, vector search, API, frontend, MCP, external tools, scheduler, runtime, and security policies can easily become tangled without clear boundaries. Clean Architecture helped keep the core logic independent from every integration.

---

🏆 Accomplishments that we're proud of

✨ A real personal-AI architecture

NEXUS goes beyond a traditional chatbot. It was designed around persistent memory, agentic planning, reusable skills, tool execution, permissions, human approval, MCP, always-on workflows, and runtime isolation, all working together as one coherent architecture rather than a set of disconnected demos.

🔐 Separating intelligence from authorization

One of our best decisions was refusing to let the LLM be the security authority: Reasoning → Validation → Authorization → Execution. We believe this pattern can be useful for many future agentic applications.

👤 User-controlled memory

Persistent memory should never become an invisible data-collection mechanism. NEXUS treats it as a capability owned by the user, who can understand what is remembered and remove it.

🧩 Reusable skills

Instead of hard-coding every capability into the agent, we built a modular architecture that makes NEXUS easy to extend and lets it grow into a broader personal AI platform.

🛡️ Security from day one

Security was not bolted on at the end. The Trust Engine, Memory Firewall, MCP boundaries, human-in-the-loop flow, runtime isolation, and fail-closed behavior are all part of the core design.

🟩 NVIDIA and Nebius in the architecture

Nemotron provides the agent's reasoning, and Nebius provides the inference infrastructure. NEXUS wraps that intelligence in its own application-level controls, exploring how NVIDIA's open models can be one part of a larger personal AI system, not merely the backend of a chatbot.

---

📚 What we learned

Building an AI agent is not the same as building a chatbot.

A chatbot needs to generate good answers. An agent must reason about actions, interact with external systems, maintain state, handle failures, respect permissions, and operate safely over time.

🧠 Intelligence is only one part of an agent

A powerful model does not automatically produce a trustworthy agent. It takes: Model + Memory + Planning + Tools + Authorization + Execution + Isolation + Observability.

🔒 Permissions must be deterministic

We do not want the model to decide:

❌ "I think this action is safe, so I'll run it."

We want:

✅ "I want to perform this action. The system will determine whether I'm allowed to."

🗃️ Memory needs governance

The system must be able to answer:

• What should be remembered?
• Why should it be remembered?
• How long should it persist?
• Who can access it?
• Can the user delete it?

Memory policy matters as much as memory storage.

🚦 Autonomy needs boundaries

Autonomy requires permissions, limits, cancellation, observability, error handling, resource controls, and human approval when appropriate.

🎯 The goal is not maximum autonomy. It is useful autonomy within clearly defined limits.

🔌 MCP is not security

MCP solves an integration problem, not an authorization problem. That distinction shaped the entire architecture.

💥 Expect failure

Agents can fail because:

• A tool is unavailable
• A permission expires
• The model produces an invalid plan
• An external service returns unexpected data
• A job times out
• The runtime becomes unavailable

A robust agent needs explicit failure states.

---

🚀 What's next for NEXUS

NEXUS is designed as a foundation that can grow well beyond the initial implementation.

🧩 More personal skills

Email · Messaging · Advanced calendar · Project management · Personal finance · Smart home · Cloud services · More developer tools.

🧑‍🤝‍🧑 Custom agents

Specialized agents for different areas of your life: Study Agent · Work Agent · Developer Agent · Research Agent · Personal Assistant.

Each one with its own skills, memory scope, permissions, instructions, schedules, and execution limits, all governed by the same Trust Engine.

🌅 More advanced proactive workflows

• Preparing daily summaries
• Monitoring recurring tasks
• Detecting upcoming deadlines
• Preparing information before meetings
• Running scheduled research
• Suggesting actions based on user-defined goals

Everything will remain governed by explicit permissions and execution limits.

🔐 Stronger security and privacy

Prompt injection resistance · Memory poisoning protection · Credential isolation · Tool security · Runtime sandboxing · User isolation · Audit logs · Rate limiting · Permission expiration · Security testing.

🔭 Better observability

A transparent activity timeline so you can always see why the agent did something: what the agent received → what memory it used → what it planned → which permission it requested → what was executed → what result was received.

🌐 A true Personal AI Operating System

The long-term vision is for NEXUS to be a persistent AI layer between you and your digital environment. Instead of dozens of disconnected AI tools, one personal system that understands your context and coordinates authorized capabilities:

Memory + Skills + Tools + Trust + Autonomy = Personal AI Operating System

We are not trying to build another chatbot. We are building toward a system that can remember what matters, understand what you need, plan what should happen, ask when approval is needed, act through trusted tools, and learn from the results.

And above all, you stay in control.

---

📘 Glossary

• LLM: large language model, the AI that reasons and generates text (here, NVIDIA Nemotron).
• Agent: an AI system that doesn't just answer but plans and takes actions using tools.
• Skill: a modular capability (e.g., Calendar) exposing a limited set of controlled actions.
• Trust Engine: the deterministic rule system that returns ALLOW, ASK, or DENY for each action.
• Memory Firewall: a policy layer controlling what is allowed to become permanent memory.
• MCP: Model Context Protocol, a standard way to connect AI systems to external tools.
• Prompt injection: an attack where untrusted content tries to give the AI hidden instructions.
• Human-in-the-loop: a design where the user approves meaningful actions before they run.
• Sandbox / Isolation: a restricted environment that limits what code can access on the host machine.
• Idempotency: a property ensuring that running the same job twice doesn't cause duplicate effects.
• Fail-closed: when something is uncertain or broken, the system denies the action by default.
• pgvector: a PostgreSQL extension for storing and searching vector embeddings.
• Clean Architecture: a design approach keeping core logic independent of frameworks and infrastructure.

---

NEXUS is not an AI that replaces the user.

It is an AI that works **with* the user.*

Built With

• agent
• agentic-ai
• docker
• ia
• llm
• mcp
• nebuis
• nebuis-token-factory
• nvidia-nemotron
• pgvector
• postgresql
• python
• sandboxing