How Haven works
A system for personal intelligence
Haven is powered by the Anywhere Intelligence Operating System (AIOS), a neurosymbolic framework combining statistical inference with deterministic engines for classification, retrieval, planning, inference, verification, permissions, explainability, and action.
One spine.
Different paths.
Every prompt enters Haven the same way. Chat Ingress prepares the turn, Chat Pipeline classifies your question and moves it through the system, and Chat Egress returns the result. Most questions remain ordinary conversation. More complex work branches into planning, research, retrieval, inference, verification, and action as needed.
establish identity · conversation · boundaries · open the trace
deliver response · persist the completed turn · close the trace
Technical note
Haven is powered by AIOS, an operating system for personal intelligence built by Anywhere Intelligence that combines stochastic and deterministic subsystems into a single local execution spine. Classifier performs semantic classification and routing before generation; the Planner / PlanExecutor turns actionable requests into bounded plans; Navigator gates capability access against the HelperObjectRegistry; and Navigator acts as the execution chokepoint, routing native macOS operations through the Native Capability Broker and third-party service calls through the Foreign Capability Broker. Knowledge retrieval and context assembly feed local inference (currently Google Gemma 4 E4B), while Verification gates generated output and the Intelligence Processing Unit records processing and governance events across the turn.
A different kind of AI.
Haven wasn’t designed around a language model. We designed it as a standalone intelligence system, capable of understanding a request, remembering, retrieving knowledge, planning, asking permission, verifying, and acting.
Use the language model for language.
Haven doesn’t send every request directly to a language model. It first classifies the turn, retrieves relevant knowledge, assembles context, and routes structured work into the systems responsible for planning and execution. Only then does the Inference system use a language model to generate text, with Verification checking output accuracy before Chat Egress returns it.
Technical note
Inference is a deliberately narrow stage inside Chat Pipeline. It receives a prepared context bundle from the systems upstream of it and returns generated text downstream to Verification; it does not control permissions, capabilities, routing, or operating-system access. Current local inference runs Google Gemma 4 E4B with Metal acceleration. Haven also supports user-configured external language models for workloads that benefit from larger models, while local inference remains the default path.
Classify before you generate.
Haven uses a compact learned classifier — GSIC, the Geometric Superposition Intent Classifier — to understand and route each segment of a request. A single prompt enters a shared high-dimensional classification space where semantic intent and routing are resolved together, becoming progressively more specific across four levels of classification.
Technical note
GSIC runs on a frozen all-MiniLM-L6-v2 sentence encoder producing a 384-dimensional representation. A learned 384 → 256 projection creates a normalized routing space, while specialized heads read either that projected representation, the original 384-dimensional embedding, or both. Across four levels, semantic intent classification and routing progressively narrow from broad eligibility and route family toward increasingly specific HelperObject and operation decisions. Deterministic detectors complement the learned geometry where exact lexical or syntactic signals are more reliable.
Memory is part of the system.
Haven doesn’t treat memory as a transcript archive. It turns useful parts of your interactions and local knowledge into persistent personal context — text, structured relationships, and higher-level summaries that can be retrieved when they matter. Personal memory is searched separately from conversation history, local reference sources, and the web, then assembled into context before inference.
Knowledgememories · relationships
summaries · meaning
Technical note
Haven’s Personal Knowledge Layer stores user-owned knowledge in multiple forms, including text chunks, structured triples, and synthesized wiki-style pages. Retrieval treats personal memory, conversation history, local reference knowledge, and web sources as distinct evidence channels before ContextAssembler combines selected results into the context bundle used downstream. Memory remains local, inspectable, and deletable by the user.
Plan before you act.
When a request requires action, Haven turns it into a structured plan before execution begins. The plan defines the intended capability and operation, then resolves the concrete values it needs — a contact, file, date, destination, or draft — before acting on them. Haven seeks approval for both the initial plan shape and final resolved values, asking for clarification when uncertain.
“Email Sarah the report.”
Resolved valuesSarah → sarah@example.com
report → Q3-report.pdf
draft → rendered message
Technical note
Planner and PlanExecutor are separate systems within Chat Pipeline, providing deterministic oversight of prompt-segment decomposition, HelperObject assignment, step-by-step plan formation, plan-shape approval, value resolution, final authorization, and execution. As needed, they call cross-system services that support plan implementation, including specialized systems for reasoning, knowledge retrieval, inference, and explainability.
The model doesn’t get the keys.
Even after a plan is authorized, Haven never gives the language model direct access to macOS or your connected accounts. Actions exist only as registered Helper Objects with known capabilities and operations, and every dispatch passes through Navigator before it can cross the system boundary. Native Mac capabilities and third-party services travel through separate controlled paths. The model can contribute language to the workflow, but it cannot improvise a capability or bypass the permission architecture.
Mail · Messages · Calendar · Files
Gmail · Slack · Notion · MCP / REST
Outside the capability chain
Technical note
The HelperObjectRegistry defines Haven’s registered capabilities and operation IDs; Navigator separately authorizes their use at dispatch. Native macOS operations cross the Native Capability Broker (NCB), while third-party operations cross the Foreign Capability Broker (FCB). Credentials remain local, including secrets protected by macOS Keychain. Language inference has no direct dispatch path or OS permission authority.
Every turn leaves a trace.
Every interaction in Haven opens an IPU — Intelligence Processing Unit — at ingress and closes it at egress, with emitters for key system events. The IPU records how the turn moves through the system — classification, knowledge, planning, inference, verification, and outcome — with governance events such as approval and authorization recorded alongside turn history. For durable actions, the trace is also an approval gate, providing authority to proceed before durable effects occur.
IPU opens · Chat Ingress
Processing
Governance
Trace closes · Chat Egress
Technical note
The Intelligence Processing Unit records processing and governance as separate axes of the same local trace. Classification, retrieval, planning, inference, verification, approvals, authorizations, and terminal outcome can therefore be reconstructed from one append-only ledger. For durable effects, required trace state is written before execution proceeds; failure to establish the required record prevents the effect rather than producing an explanation after the fact.
Generation is not the final step.
Haven treats generated text as an intermediate result, not a finished answer. Verification sits between Inference and Chat Egress, checking output against the same context Haven supplied to the language model. It also compares selected facts against recent conversation history and applies stricter grounding rules to volatile, real-time claims. Two further checks ask whether the response should be released at all: one screens for universal harm, the other holds the response to rules you have stated yourself. When a check fails, Haven can stop the response before release, retry generation with corrective context, or suppress an unsupported claim rather than letting the model guess.
One of three outcomes
Technical note
Verification is a streaming gate within Chat Pipeline, evaluating generated output against the provenance and recent chat context used for that turn, and against universal-harm and user-alignment rules. Blocking failures can interrupt generation before release and trigger a bounded retry; persistent contradictions are disclosed, while unsupported real-time fabrications are suppressed in favor of abstention. The same verification path is used for generated plan artifacts, including drafts awaiting user approval.
One Mac. The whole system.
Haven doesn’t run in a data center with your Mac acting as a terminal. Its intelligence, personal knowledge, permissions, and core compute live on your machine. When you search the web or connect a service such as Gmail, Notion, GitHub, or Slack, Haven reaches across that boundary only for the external data or capability you’ve authorized. The system itself stays local. That is what allows ordinary Haven conversations to remain private and unmetered — no Haven cloud subscription, no token meter, and no tracking infrastructure required to make the product work.
Your Mac
External sources + helpers
Technical note
Haven’s core AIOS path and persistent personal state run locally on the Mac. Web access and third-party Helper Objects cross explicit external boundaries only when invoked, while their routing, permissions, credentials, and execution controls remain local. Local inference means ordinary Haven conversations do not depend on a hosted Haven model service or metered token API.
Architectural comparison
A model is not a system.
Haven runs a local language model. So do other things. The difference is everything around it.
| Dimension | Cloud LLM | LLM + RAG | Local LLM | Haven |
|---|---|---|---|---|
| Primary architecture | The model is the system. | The model, with retrieval attached. | The same model-centered design, on your hardware. | The model is one stage. The system classifies, remembers, plans, authorizes and verifies around it. |
| Personal memory | Held by the provider, scoped to your account. | Documents you attached, retrieved on demand — not memory of you. | Chat history at best. No model of you. | A local knowledge layer you own, built from your interactions and revisable by you. |
| Planning and action | The model chooses its own tool calls. | Retrieval feeds generation. Nothing acts. | The model chooses; a client confirms each call. | Planning is separate from generation. You approve the plan, then authorize the action. |
| Credentials and access | Tokens live with the provider or the app. | Spread across the app, the index, and the model host. | Tokens in a plaintext config file. | Credentials stay in the Mac keychain. The model never receives them. |
| Verification | Safety filters, not accuracy checks. | Citations you can check yourself. Nothing checks the claim. | Nothing between the model and you. | Grounding and accuracy checked before release. It can retry or abstain. |
| Traceability | A reasoning summary, not a record of decisions. | Sources shown. The decisions are not. | Nothing recorded unless you add it. | An append-only local record of every processing and governance event. |
Primary architecture
- Cloud LLM
- The model is the system.
- LLM + RAG
- The model, with retrieval attached.
- Local LLM
- The same model-centered design, on your hardware.
- Haven
- The model is one stage. The system classifies, remembers, plans, authorizes and verifies around it.
Personal memory
- Cloud LLM
- Held by the provider, scoped to your account.
- LLM + RAG
- Documents you attached, retrieved on demand — not memory of you.
- Local LLM
- Chat history at best. No model of you.
- Haven
- A local knowledge layer you own, built from your interactions and revisable by you.
Planning and action
- Cloud LLM
- The model chooses its own tool calls.
- LLM + RAG
- Retrieval feeds generation. Nothing acts.
- Local LLM
- The model chooses; a client confirms each call.
- Haven
- Planning is separate from generation. You approve the plan, then authorize the action.
Credentials and access
- Cloud LLM
- Tokens live with the provider or the app.
- LLM + RAG
- Spread across the app, the index, and the model host.
- Local LLM
- Tokens in a plaintext config file.
- Haven
- Credentials stay in the Mac keychain. The model never receives them.
Verification
- Cloud LLM
- Safety filters, not accuracy checks.
- LLM + RAG
- Citations you can check yourself. Nothing checks the claim.
- Local LLM
- Nothing between the model and you.
- Haven
- Grounding and accuracy checked before release. It can retry or abstain.
Traceability
- Cloud LLM
- A reasoning summary, not a record of decisions.
- LLM + RAG
- Sources shown. The decisions are not.
- Local LLM
- Nothing recorded unless you add it.
- Haven
- An append-only local record of every processing and governance event.
Rows describe the default architecture of each approach, not the ceiling of what can be built on one. Real products mix these shapes.
Personal AI belongs on personal computers.
We’ve made this journey before, progressing from mainframes to personal computing devices. AI is reaching the same turning point. As models become more efficient, intelligence is moving out of hyperscale data centers and onto personal computers — becoming more personal, trustworthy, and accessible.