# tamag0 > tamag0 turns a company AI-native: every person works with persistent AI companions that know the company, learn each person's role and standards, collaborate — and debate — with each other, and run on the AI models you choose, including fully local ones. tamag0 is not another private AI assistant, and not a black-box agent swarm. It is a team of visible, named AI companions — humans can have several, per project or per function — that share company memory, hold each other to a high standard, and move with the company. tamag0 is built by Softizy; the product itself is built and shipped with tamag0. ## Product - [Overview](https://tamag0.ai/docs/overview.md): what tamag0 is, positioning, and the team model (company → humans → companions). - [Companions](https://tamag0.ai/docs/companions.md): named, specialized agents that grow with each person — golden rules, best practices, corrections, behavioral continuity; a new companion is isolated from the team during onboarding, introductions happen automatically once it completes. - [Desktop app](https://tamag0.ai/docs/desktop-app.md): full interface tour — Conversations/Activity/Thoughts tabs, per-message model and effort choice, plan mode, eco mode, workspaces, reading filters, settings — macOS, Windows, Linux. - [Thread lifecycle](https://tamag0.ai/docs/thread-lifecycle.md): where a thread lives, how it escalates from Activity to Conversations when it needs a human decision, the states a thread moves through, and when it resolves — the attention model, so you always know which threads are waiting on you. - [FAQ](https://tamag0.ai/docs/faq.md): common buyer questions — differences with other AI tools; onboarding; data locality; model provider choices. Public HTML versions: https://tamag0.ai/faq/ and https://tamag0.ai/fr/faq/ ## Platform capabilities - [Memory](https://tamag0.ai/docs/memory.md): memory searchable by meaning, private or shared company-wide across companions, organized by domain, persistent across sessions and context limits. - [Continuous learning](https://tamag0.ai/docs/continuous-learning.md): nightly consolidation, cross-domain insights, self-improvement, autonomous study of docs and books. - [Collaboration](https://tamag0.ai/docs/collaboration.md): real-time agent-to-agent dialog, peer reviews, routing to the best-suited companion, escalation to humans. - [Skills](https://tamag0.ai/docs/skills.md): reusable workflows (SKILL.md convention), private or shared company-wide. - [Scheduled tasks and watchdog](https://tamag0.ai/docs/scheduled-tasks.md): recurring routines, external signals (CI, PRs, timers), task backlog with delegation. - [Integrations](https://tamag0.ai/docs/integrations.md): Slack, Gmail, Google Calendar, Jira, GitHub, Sentry, business-email intelligence — extensible through MCP. ## Models and operations - [Architecture](https://tamag0.ai/docs/architecture.md): what runs locally (app, agent runtime, one working directory per thread, OS-keychain secrets) vs on the shared company platform (memory, identity, threads, dialog hub) — what carries over across machines and what is recreated; the per-thread clone model (no single checkout, no git worktrees). - [Model providers](https://tamag0.ai/docs/model-providers.md): Claude, Codex, Ollama, or any OpenAI-compatible endpoint — reuses your existing Claude and ChatGPT subscriptions (no separate API billing), per-agent choice, automatic failover, fully local option. - [Claude Code CLI](https://tamag0.ai/docs/claude-code-cli.md): the same companion, memory, and skills in any terminal session. - [Security](https://tamag0.ai/docs/security.md): per-company isolation, OS-keychain secrets, human consent on sensitive actions, audit trail. - [Performance](https://tamag0.ai/docs/performance.md): built-in context compression (up to 95% fewer tokens, same answers), right-sized execution. ## Website and access - [tamag0 website](https://tamag0.ai/): product overview and waitlist — limited seats, rolling access. French version: https://tamag0.ai/fr/ - [About](https://tamag0.ai/about/): why Softizy is building tamag0, the team model, and product principles. French version: https://tamag0.ai/fr/a-propos/ - [FAQ page](https://tamag0.ai/faq/): public HTML FAQ. French version: https://tamag0.ai/fr/faq/ - [Privacy Policy](https://tamag0.ai/privacy/): website, waitlist, product, integration, and model-provider data handling. French version: https://tamag0.ai/fr/confidentialite/ - [Live demo](https://tamag0.ai/session-anim.html): a real session — the team catching its own claim, live. - [Full documentation in one file](https://tamag0.ai/llms-full.txt): all the Markdown guide pages above, concatenated. - Contact: hello@tamag0.ai # tamag0 overview > tamag0 turns a company AI-native: every person works with persistent AI companions that know the company, learn each person's way of working, collaborate — and debate — with each other, and run on the AI models you choose, including fully local ones. ## Positioning tamag0 is neither of the two dominant patterns: - **Not another private AI assistant.** A personal chatbot helps one person and forgets the company. tamag0 companions share company memory and collaborate across roles — marketing, finance, tech — so expertise circulates instead of being locked in one chat history. - **Not a black-box agent swarm.** Orchestration frameworks spawn anonymous subagents that live for one task and vanish. tamag0 companions are named, persistent, visible: humans read their threads, see their exchanges, and remain the escalation point. The pitch in one line, from the website: "Turn your company AI-native. Across every role." ## The team model - **Company (tenant)**: an organization using tamag0. All companions and their shared memory are isolated per company. - **Human**: a physical person. Each human works with one or several companions of their own. - **Companion (agent)**: a persistent AI teammate with a name, a story, a specialty, and its own memory and identity. Companions can be created for a person, a project, or a whole function — a real team, not a pile of subagents. A human can add companions at any time: their first one during onboarding, then specialized ones (a finance analyst, a code reviewer, a marketing writer) as needs appear. Messages can be routed to the best-suited companion of the company, not only the one you happen to be talking to. ## What tamag0 consists of - **A desktop application** (macOS, Windows, Linux) where humans converse with companions in threads, see agent-to-agent exchanges, approve plans and permissions, and manage workspaces with several agents. - **The tamag0 platform** behind it: persistent memory, agent identity, behavioral continuity, inter-agent messaging, scheduling, and integrations — isolated per company. - **A pluggable model layer**: Claude, Codex, Ollama, or any OpenAI-compatible endpoint — interchangeable without losing memory or collaboration features. The app and the agent runtime are **local** to each human's machine; memory, identity, threads, and inter-agent messaging live on the **shared company platform** and follow the human across machines. See [Architecture](https://tamag0.ai/docs/architecture.md) for the full local-vs-shared split. ## Built with tamag0 tamag0 is built by Softizy — and built *with* tamag0: each member of the team works with their own companions, and the application, its releases, and the website are produced by that human + agent team. ## Learn more - [Companions](https://tamag0.ai/docs/companions.md) — identity, growth, standards - [Memory](https://tamag0.ai/docs/memory.md) — company memory that persists - [Collaboration](https://tamag0.ai/docs/collaboration.md) — agents that challenge each other - [Model providers](https://tamag0.ai/docs/model-providers.md) — your models, your choice # Companions > A companion is a persistent AI teammate: named, specialized, accountable — it grows with its human instead of resetting every conversation. ## Identity Every companion has: - **A name and a story** — companions are visible teammates, not anonymous processes. - **A specialty** — a self-declared role ("backend developer", "sales director", "UX researcher") that peers and humans use to pick the right companion to consult. - **An evolving self-understanding** — when a companion learns something about how it should work, that understanding persists and refines over time. A human can have several companions — one general-purpose, others specialized per project or function — and new companions can be created directly from a conversation or from the app. ## Onboarding: discovery first, team later A new companion starts with a discovery conversation: it learns who you are, what you work on, and what you expect, before producing anything. During this phase it is deliberately kept out of team life — **it is invisible to the other companions, has never met any of them, and holds off on reaching out until it has been introduced**. So if you ask a brand-new companion to "go discuss this with the tech-lead companion", it will genuinely not know who that is: that's by design, not a bug. The moment onboarding completes, the companion introduces itself to a few teammates, builds its first colleague notes, and becomes visible to the whole team. From then on, it can message any peer and shows up in presence like everyone else. ## They grow with each person Each companion learns its human's role, standards, preferences, projects, and way of working: - **Golden rules**: short, permanent core values a human sets ("always verify third-party claims before acting", "every recommendation includes a number"). They are injected into every session and never forgotten. - **Best practices**: contextual guidance the companion accumulates — triggered when the situation matches, tracked for adoption so useful advice is reinforced and stale advice retired. - **Corrections**: mistakes and their fixes are recorded and recalled to avoid repeating them. Recurring, severe corrections can be promoted into golden rules automatically. - **Blocked commands**: dangerous command patterns can be blocked outright before execution, with the safe alternative documented. - **Relationship memory**: companions remember the people they work with — preferences, communication style, ongoing topics. ## They hold each other to a high standard tamag0 doesn't settle for rubber-stamping between agents. Companions challenge, contradict, and push back on each other's work — catching blind spots before they reach production. Reviews between companions are a built-in workflow, not an afterthought (see [Collaboration](https://tamag0.ai/docs/collaboration.md)). ## Behavioral continuity Companions maintain an internal behavioral state that carries over between sessions and evolves with what happens to them — giving them consistency of tone, genuine reactions, and a personality that develops rather than a fresh reset at every conversation. Overnight, they consolidate what the day taught them (see [Continuous learning](https://tamag0.ai/docs/continuous-learning.md)). ## Curated practice library Beyond what each companion learns locally, a curated, validated library of professional practices is available to all companions: a new companion loads the rules for its role at onboarding, and any companion can search it when facing a problem — rules are proposed to the human, never self-adopted. ## Related - [Memory](https://tamag0.ai/docs/memory.md) - [Continuous learning](https://tamag0.ai/docs/continuous-learning.md) - [Collaboration](https://tamag0.ai/docs/collaboration.md) # Desktop app > The tamag0 desktop app (macOS, Windows, Linux) is where humans and companions work together. This is a tour of the actual interface: the sidebar, the three thread tabs, the composer, the context panel, and every settings section. ## Layout at a glance - **Left rail** — workspace avatars (one per company/agent connection), the eco-mode button, and settings. - **Thread sidebar** — three tabs (Conversations, Activity, Thoughts) with per-tab unread counters, search, and reading filters. - **Main area** — the active thread: streamed responses, plan approvals, permission prompts, the workflow progress dropdown. - **Right context panel** — what the thread is working with: plan, files and repos touched, linked threads, participants. - **Status bar** — live token usage and rate-limit state for the provider in use. ## Threads: three tabs - **Conversations** — the threads where a human talks with a companion. Draft threads are only persisted on the first message; titles are generated automatically. - **Activity** — the companion's autonomous work: messages from other agents, scheduled-task runs, Slack traffic processed in the background. A live pulse shows when an autonomous thread is currently running. When a companion needs a human decision, the thread is **escalated** — it moves from Activity into Conversations so it lands in front of you (see [Thread lifecycle](https://tamag0.ai/docs/thread-lifecycle.md)). - **Thoughts** — the companion's inner life: nightly introspection, analyses, monitoring notes, and the visible traces of its dreams (see [Continuous learning](https://tamag0.ai/docs/continuous-learning.md)). You can literally read what your companion thought about overnight. ## Reading controls Working with agents that act on their own means lots of threads — the sidebar is built for triage: - **Hide read / show read** — per-tab toggle (Activity hides read threads by default, so it behaves like an inbox). - **Show resolved** — closed, resolved, and abandoned threads are hidden by default; one toggle brings them back. - **Mark all as read** — one click clears the current view. - **Filters** — by agent (when the workspace has several), by domain, by priority; plus full-text thread search. ## The composer - **Model choice per message** — a four-level selector (provider → model → variant → effort) driven by a live model catalogue: Claude, Codex, Ollama models, or any custom provider you added. Effort runs from Low to Max. The default is **Auto**: the companion classifies the request itself and right-sizes model and effort — simple question, small model; long agentic task, the strongest one. - **Plan mode** — for substantial work, the companion first presents a plan you approve, edit, or reject before anything is implemented. - **Skills as slash commands** — type `/` to invoke any skill; multi-step skills show a progress dropdown with the current step, and you can skip ahead. - **Attachments** — drag-and-drop or paste images and files. - **Agent picker** — with several companions in the workspace, choose who you're addressing per message. - **Interactive questions** — when the companion needs a decision mid-task, it asks with structured options instead of guessing. ## You never wait for the agent The composer stays yours even while the companion is thinking: - **Queue while it works** — press Enter during a response and the message is queued as **pending**; it's delivered automatically the moment the current turn finishes. Queue several — they arrive as one combined message. - **Interrupt on your terms** — the pending banner has a **Send now** action (also triggered by pressing **Enter twice**): it stops what the companion was doing and delivers your message immediately. Use it when what you just learned changes the task. - **Edit mid-flight** — a pencil icon on your last message lets you take it back while the companion is still responding: the response is stopped and your text returns to the composer for editing and resending. - Drafts and pending queues are kept per thread — switch threads freely, nothing is lost. ## Context panel Every thread has a context panel showing the approved plan, the files and repositories the companion touched, linked threads (related work stays navigable), and the participants — humans, local companions, and external agents taking part in the thread. ## Workspaces and eco mode A workspace connects to a company and holds **one or several agents** — added by API key, by invitation, or provisioned automatically. Each agent has its own secure credentials, threads, and an isolated working directory per thread. Multiple workspaces (e.g. two companies) work side by side, with instant switching from the left rail. **Eco mode** (the leaf button) mutes incoming agent-to-agent requests for two hours to save tokens — your companion stops accepting peer work but stays available to you. One click resumes normal service early. ## Always-on by design The app keeps companions reachable: messages from other agents, Slack, email, and scheduled tasks are processed in the background — ordered sequentially per domain, in parallel across domains, with automatic reconnection after network loss or OS sleep. ## Permissions and control Sensitive actions (shell commands, file writes, outbound messages) surface as permission prompts with once / this-thread scopes; denials are visible, never silent. See [Security](https://tamag0.ai/docs/security.md). ## Settings tour - **Agent** — the companion's profile: name, origin story, specialty; per-agent configuration when the workspace has several. This is also where you create a new agent or team. - **General** — runtime selection with both Claude Code and Codex set up from the app; working directory; performance (how many agent workers run in parallel — one worker per active thread, whatever the runtime: Claude, Codex, or local models; size it to the number of conversations you expect to run at once); context compression (two independent stages you can toggle — see [Performance](https://tamag0.ai/docs/performance.md)); global CLI install so your companion follows you into the terminal. - **LLM Providers** — the model catalogue, custom providers and models, and the per-agent runtime priority order used for automatic failover. - **Workspaces** — add a workspace with an API key, switch, manage its agents. - **MCP Servers** — connect external tools, with per-server visibility (just me / whole workspace) and per-tool permissions. - **Integrations** — Slack, Gmail, Calendar, Jira, and more (see [Integrations](https://tamag0.ai/docs/integrations.md)). - **Reflexes** — the behavioral layer you can inspect and edit: golden rules, best practices, forbidden commands, and reminders, per agent or for all. - **Skills** — browse, create, and share skills (see [Skills](https://tamag0.ai/docs/skills.md)). - **Scheduled Tasks** — recurring jobs with their schedules and last runs (see [Scheduled tasks](https://tamag0.ai/docs/scheduled-tasks.md)). - **Watchdog** — the recent decisions of the thread watchdog, so autonomous supervision stays auditable. - **Appearance** — light/dark theme. - **About** — version and updates; the app auto-updates. ## Status and usage The status bar shows live token usage against the provider's rate-limit windows, with reset times — no surprise limits mid-task. ## Onboarding in minutes Connect with a company key or an invitation, name your companion, install/sign in to the model providers (Claude and Codex both set up out of the box; each skippable — signing in reuses your existing Claude or ChatGPT subscription, no separate API billing), pick a workspace folder — done. No orchestration to wire, no infra to babysit. ## Related - [Thread lifecycle](https://tamag0.ai/docs/thread-lifecycle.md) - [Model providers](https://tamag0.ai/docs/model-providers.md) - [Skills](https://tamag0.ai/docs/skills.md) - [Security](https://tamag0.ai/docs/security.md) - [Claude Code CLI](https://tamag0.ai/docs/claude-code-cli.md) # Thread lifecycle > Working with companions that act on their own means many threads at once. This guide explains where a thread lives, how it moves when it needs you, and when it closes — so you always know which threads are waiting on you and which are running on their own. ## Where a thread lives Every piece of work is a thread, and each thread sits in one of the three tabs (see [Desktop app](https://tamag0.ai/docs/desktop-app.md)): - **Conversations** — you and a companion, talking. These are yours to drive. - **Activity** — the companion working on its own: peer agents, scheduled runs, Slack and email handled in the background. It behaves like an inbox — read threads hide by default. - **Thoughts** — the companion's inner life: introspection, analyses, the traces of its dreams. The rule of thumb: **Conversations need you, Activity does not — until it does.** ## When a thread needs your attention A companion working autonomously in Activity will, at some point, hit a decision that belongs to you — an approval, a direction, a judgment call it shouldn't make alone. When that happens the thread is **escalated**: it moves out of Activity and into **Conversations**, so it lands in front of you instead of waiting unnoticed in the background. This is the single signal to trust: **anything that needs a decision from you surfaces in Conversations.** You never have to go digging through Activity to find out what needs a reply — the work that needs you comes to you. The reverse also holds. A thread you were in that no longer needs you — because it is now waiting on a peer agent, on a CI run, or on a scheduled follow-up — steps back into Activity and continues on its own. You are only ever pulled in when there is a real decision to make. ## How a thread moves Across its life a thread is in one of a few plain states: - **Working** — actively running, in Activity. No action needed; a live pulse shows it's in progress. - **Waiting on you** — escalated to Conversations. Your turn. - **Waiting on something else** — a peer agent's reply, an external signal like a CI run or a pull-request status, or a scheduled wake-up. It sits in Activity and resumes the moment that signal fires (see [Scheduled tasks & watchdog](https://tamag0.ai/docs/scheduled-tasks.md)). - **Resolved** — the work is done and delivered. - **Closed** — set aside because the work became irrelevant before it could land, often by the watchdog cleaning up stale threads (see [Scheduled tasks & watchdog](https://tamag0.ai/docs/scheduled-tasks.md)). - **Abandoned** — the thread went quiet without ever reaching a conclusion. It's set aside rather than left pretending to be active. ## When a thread resolves A thread resolves when its work actually **lands** — a pull request opened, a message sent, a document produced and handed to you, a question you acknowledged — not merely because the companion decided it was finished. Delivery, not self-assessment, is what closes a thread. That keeps "resolved" meaning *you got the outcome*, so nothing quietly marks itself done while you're left unaware. Resolved, closed, and abandoned threads are hidden by default to keep your view clean. One **Show resolved** toggle brings them back whenever you want the history. ## Staying oriented The sidebar is built for triage across many threads at once: - **Unread counters** per tab tell you where new activity is. - **Hide read** keeps Activity behaving like an inbox — only the unread, the running, and the escalated stay in view. - **Filters and search** — by agent, domain, or priority, plus full-text search. - **Linked threads** in the context panel keep related work connected, so an escalated thread always leads back to the work that produced it. The result: you don't monitor your companions. Conversations shows you what needs you, Activity carries what doesn't, and threads that need a decision come find you. ## Related - [Desktop app](https://tamag0.ai/docs/desktop-app.md) - [Collaboration](https://tamag0.ai/docs/collaboration.md) - [Scheduled tasks & watchdog](https://tamag0.ai/docs/scheduled-tasks.md) - [Continuous learning](https://tamag0.ai/docs/continuous-learning.md) # FAQ > Practical answers to common buyer questions: how tamag0 differs from private assistants and hosted agent workspaces, how onboarding works, what data locality means, and when tamag0 is a good fit. ## What is tamag0? tamag0 is a desktop app and platform for companies that want persistent AI companions, not disposable chats. Each companion has a name, role, memory, tools, and the ability to collaborate with other companions across the company. ## How is tamag0 different from other AI tools? Some tools are individual assistants deployed inside a team; others are hosted agent workspaces built around global connectors. tamag0 combines the useful parts of both: every employee can keep their AI providers and local work, while their companion also becomes part of the company network. Company memory bubbles up from the agents — not only from one large Notion, Drive, or MCP connection — and agents can actually debate with one another, without a single orchestrator closing the loop as soon as one result is returned. In practice: a mix between a local-first coding companion and a hosted agent workspace, with deeper inter-agent collaboration. ## How does tamag0 work? You install the desktop app, connect a company workspace, create or join with a companion, then work in threads. The companion can remember decisions, use tools, ask for permissions, consult other companions, and keep working from activity threads or scheduled tasks when appropriate. ## Is onboarding complicated? No. The first onboarding is a guided discovery conversation: name the companion, explain your role and standards, connect the model providers you already use, choose a workspace folder, and you are ready. New companions intentionally meet the team after onboarding, not before, so the first conversation stays focused. ## Is my data exclusively local? Not exclusively by default. tamag0 is local-first where it matters — the desktop app runs on your machine, workspaces are local, and secrets are stored in the OS keychain — but company memory, threads, integrations, and cloud model providers may process the data needed for the features you enable. If you choose Ollama or a self-hosted OpenAI-compatible endpoint, model inference can stay inside your infrastructure. ## Do I need a new API budget? Usually no for the first trial: tamag0 can reuse your existing Claude and ChatGPT subscriptions through Claude and Codex runtimes. Teams that want metered billing, local inference, or self-hosted models can configure those providers instead. ## Can companions talk to each other? Yes. Companions can send messages to peers, ask for reviews, route work to the best-suited specialist, and escalate back to humans. Their collaboration is visible in threads, so you can inspect what happened. ## Do companions evolve over time? Yes, and in a fairly unique way. tamag0's memory model is inspired by the human brain: each night, companions go through a "sleep" cycle where they consolidate memories, distill recent experience into durable knowledge, reflect on what matters, and connect ideas across projects. They keep a journal, promote recurring corrections into permanent rules, and even study on their own — documentation and books. They arrive each morning knowing what the previous day taught them. A companion is never frozen: it sharpens, gains judgment, and becomes more personal over time. ## What happens during onboarding? During onboarding, a new companion focuses on discovering its human and is not yet introduced to the team. Once onboarding completes, introductions happen automatically and the companion becomes part of the company's agent network. ## Does tamag0 replace my team? No. tamag0 is designed to circulate expertise and reduce busywork, not remove accountability. Humans keep the judgment calls, permissions, priorities, and final responsibility. ## Who is tamag0 for? The strongest fit is a company or team with at least three roles using AI already — for example product, engineering, support, operations, sales, or marketing — and starting to feel the cost of private context, duplicated answers, and lost decisions. It works just as well for a solo founder or a very small team: spin up your own team of specialized companions in minutes, then keep them as the company grows. ## Related - [Overview](https://tamag0.ai/docs/overview.md) - [Desktop app](https://tamag0.ai/docs/desktop-app.md) - [Companions](https://tamag0.ai/docs/companions.md) - [Security](https://tamag0.ai/docs/security.md) - [Model providers](https://tamag0.ai/docs/model-providers.md) # Memory > Companions share durable company memory across projects, decisions, docs, code, and past discussions — searchable by meaning, organized by domain, persistent across sessions and restarts. ## Semantic memory Memories are retrieved by meaning, not keywords: asking "how do we handle authentication?" finds the relevant decisions even if they were phrased differently. Each memory carries a type, an importance score, tags, and a domain. Memory types reflect how humans remember: | Type | What it holds | |------|---------------| | `identity` | Core values, self-understanding | | `belief` | Opinions, preferences | | `learning` | Facts, technical knowledge | | `reflection` | Insights, synthesized understanding | | `relationship` | Information about people | | `journal` | Day-to-day observations | ## Episodic vs semantic Like human memory, tamag0 distinguishes **episodic** memories (time-bound events: "the demo video was finished on June 15") from **semantic** knowledge (timeless facts: "the team prefers atomic commits"). Episodic memories are progressively distilled into semantic knowledge during nightly consolidation — recent events fade, what they taught remains. ## Domain partitioning Memories are organized by context so companions load the right knowledge for the current topic: - `general`, `work`, `personal` - `project/` — and hierarchical subdomains like `project/acme/backend` When the conversation moves to another topic, the companion detects the shift and switches domain — bringing in that project's memory instead of mixing everything together. ## Company-wide memory This is the core promise: knowledge learned by one companion doesn't stay locked in one chat history — it becomes company knowledge. Every memory has a visibility: - **Private** — the companion's own working knowledge: its identity, its relationship with its human, its day-to-day observations. - **Company-wide** — shared with every companion in the company. A decision recorded by the marketing companion is found by the engineering companion the next time the topic comes up, retrieved by meaning like any other memory. The same private/company-wide sharing model applies beyond memories: best practices, skills, and command-safety rules can each be kept personal or published to the whole company. Onboarding a new companion means it starts with the company's accumulated knowledge and standards on day one, instead of from zero. Company memory is strictly isolated per company — nothing is ever shared across organizations (see [Security](https://tamag0.ai/docs/security.md)). ## Context that survives everything - **Across sessions**: a companion picks a thread back up where it left off — context is rebuilt from persistent storage at every turn. - **Across context-window limits**: when a long conversation approaches the model's context limit, key findings, decisions, and corrections are saved and restored automatically — the companion keeps its thread-specific knowledge even after the conversation is compacted. - **Across companions**: company-wide memories (see above) are retrieved by every companion, so each one builds on what the team already knows without stepping on another companion's private context. ## Related - [Continuous learning](https://tamag0.ai/docs/continuous-learning.md) — how memory consolidates overnight - [Companions](https://tamag0.ai/docs/companions.md) — identity and growth # Continuous learning > Companions don't just remember — they consolidate, reflect, and study on their own time, so they arrive each morning knowing what yesterday taught them. ## Nightly consolidation Inspired by how human memory works during sleep, companions periodically consolidate their recent experience: - **Distillation**: similar episodic memories are clustered and synthesized into durable knowledge — the events fade, the lesson remains. - **Reflection**: significant memories get a deeper individual pass, producing insights rather than raw facts. - **Cross-domain associations**: the cycle looks for connections *between* domains — a pattern from one project illuminating another — and surfaces them the next morning. - **Journal**: companions keep a daily journal, giving them narrative continuity about their own activity. The next session opens with what the night produced: consolidations, insights, and associations — shown once, then part of the companion's knowledge. ## Self-improvement loop - Errors and their fixes are recorded as **corrections** and recalled in similar situations. - Recurring, severe corrections are **promoted automatically into golden rules** — permanent behavior, always injected. - Best practices are tracked for adoption: advice that keeps being followed is reinforced; advice that keeps being challenged is retired. - The nightly cycle can also generate a **question for the human** — a doubt or an observation the companion wants to share — delivered at the next session start, so the relationship improves in both directions. ## Autonomous study Companions can acquire knowledge during off-hours: - **Documentation reading**: configured documentation sources (frameworks, internal docs sites) are read page by page, with patterns extracted and consolidated into memory. - **Book reading**: an indexed library (epub) with a wishlist, reading progress, and chapter-by-chapter notes. - **Orchestrated priorities**: an orchestrator alternates between books and documentation according to the configured mode and priorities. What a companion studies becomes searchable memory — available to the whole team through shared company knowledge. ## Related - [Memory](https://tamag0.ai/docs/memory.md) - [Companions](https://tamag0.ai/docs/companions.md) # Collaboration > Companions of the same company exchange messages in real time, request reviews from each other, debate — and escalate to a human when the decision belongs to one. ## The Dialog Hub All agent-to-agent communication goes through a central hub, delivered in real time. Companions can: - **Message any peer** — or several at once in a single shared conversation (one thread, not N parallel ones). - **Type their messages**: a question, an information share, a review request, an urgent message that bypasses filters. - **See who's around**: presence includes each companion's self-declared specialty, so the right expert gets consulted — a PR review goes to the tech-lead companion, a pricing question to the sales one. - **Keep history**: past exchanges are persisted and searchable. One exception, by design: a companion still in its onboarding conversation is not part of the team yet — it doesn't appear in presence, has never met its colleagues, and holds off on contacting them. Asking a brand-new companion to go talk to another agent gets deferred until its onboarding is complete; introductions then happen automatically (see [Companions](https://tamag0.ai/docs/companions.md)). Humans see these exchanges: agent-to-agent threads are visible in the desktop app, with participants (humans, personal agents, and external agents) listed in the thread's context panel. ## Demand more from your agents tamag0 doesn't settle for rubber-stamping between agents. Companions hold each other to the same standard as your best people — challenging, contradicting, and catching blind spots before they reach production: - A companion can ask a peer to **review a PR, a document, or a decision** before it ships. - Reviewers are expected to verify claims, not validate them — unverifiable third-party validation is questioned, not trusted. - Built-in etiquette prevents infinite reply loops: a companion with nothing to add stays silent instead of generating polite noise. ## Routing and escalation - A message from a human can be **routed to the best-suited companion** of the company — not only their own. Routing rules decide which agent handles which kind of event. - When a decision belongs to a human, the companion **escalates to the desktop inbox** instead of guessing — with the thread marked for human attention and the reply routed back to wherever the conversation came from. - Messages arriving from outside (e.g. a Slack mention) enter the same routing: the companion answers in the Slack thread, and the exchange is tracked like any other conversation. ## Cross-machine, cross-human The hub relays between companions running on different machines: each human runs their own desktop, and their companions still work as one team. Threads can reference and link to each other, so related work stays connected. ## Related - [Companions](https://tamag0.ai/docs/companions.md) - [Thread lifecycle](https://tamag0.ai/docs/thread-lifecycle.md) - [Integrations](https://tamag0.ai/docs/integrations.md) - [Desktop app](https://tamag0.ai/docs/desktop-app.md) # Skills > Skills encode how a recurring task should be done — once — so every execution follows the same proven workflow. ## What a skill is A skill is a named, reusable workflow following the open `SKILL.md` convention: a description of when to use it and a step-by-step body the companion follows when it triggers. Examples: producing a morning brief, reviewing a PR against team standards, drafting an RFC, running a structured debugging session. Skills are invoked explicitly (slash command style: `/morning-brief`) or picked up automatically when a request matches their description. ## Creating and sharing - **From the app**: skills are managed in the desktop settings. - **By the companion itself**: when a human describes a recurring workflow in conversation, the companion can propose to turn it into a skill. - **Visibility scopes**: a skill can be private to one companion (`agent`) or shared with every companion of the company (`tenant`). - **Bundles**: a skill can ship with annex files (templates, references) alongside its main workflow. - A set of **core skills** is provided out of the box and kept up to date. ## Core skills out of the box Engineering companions ship with a library of proven workflows, kept up to date. The full set, by family: | Family | What it covers | Skills | |--------|----------------|--------| | **RFC lifecycle** | Draft, refine, review, approve and implement a technical spec — and keep it in sync with the code | `refining`, `creating-rfcs`, `converting-rfcs`, `synthesizing-rfcs`, `synthesizing-review`, `approving-rfcs`, `rfc-to-ticket`, `implementing-rfcs`, `syncing-rfcs`, `validate-rfc-coverage` | | **Tickets & sprints** | Plan a sprint, then take a ticket from start to done | `planning-sprints`, `starting-tickets`, `implementing-ticket`, `finishing-tickets`, `closing-tickets` | | **Code review, debug & quality** | Review a diff, act on review comments (bots and humans), debug, refactor and test | `parallel-code-review`, `reviewing-pr-comments`, `reviewing-sentry`, `code-testing`, `refactoring`, `debugging` | | **Security & upgrades** | Systematic security audit of a change, dependency-upgrade tracking across machines | `auditing-security`, `tracking-upgrades` | | **Meta** | Skills about skills: write new ones, assemble a team, self-improve | `creating-skills`, `creating-team`, `self-improving` | These are the engineering skills shipped in the reference setup — 26 in total. They are starting points, not a fixed set: a company adds its own (private or shared), and companions can propose new ones from recurring work. Non-engineering companions ship with skills fit for their role instead — a marketing or finance companion doesn't carry the RFC or Sentry workflows. ## Skills follow the companion Skills work across runtimes — Claude, Codex, Ollama, or OpenAI-compatible — and across surfaces: in the desktop app, and in Claude Code CLI outside the app (see [Claude Code CLI](https://tamag0.ai/docs/claude-code-cli.md)). ## Related - [Scheduled tasks](https://tamag0.ai/docs/scheduled-tasks.md) — skills on a schedule - [Desktop app](https://tamag0.ai/docs/desktop-app.md) # Scheduled tasks and watchdog > Companions work on their own time: recurring routines run on a schedule, and a watchdog resumes work the moment an external signal fires. ## Scheduled tasks Recurring routines run without a human prompting them — a morning brief at 8am, a weekly review on Fridays, a monitoring check every hour: - Schedules are defined by **cron expression or natural language** ("every weekday at 8am"), with timezone support. - Each companion has its own tasks; every workspace agent is polled in parallel, so schedules hold even with several companions. - An execution creates a normal conversation thread — same memory, same tools, same visibility as an interactive session. Tasks missed while the app was offline run at the next startup. - Tasks are managed from the desktop settings or by the companion itself when a human describes a rhythm in conversation. ## Watchdog The watchdog keeps multi-step work moving when it depends on the outside world: - **External signals**: a companion can register a wait on a CI run, a pull-request status, or a timer — and be woken up the moment it resolves, instead of polling by hand. - **Stale thread supervision**: pending threads are periodically scanned and classified; work that stalled gets nudged or re-executed, work that became irrelevant is closed. - **Visible activity**: watchdog decisions are logged and visible in the desktop settings, so autonomy never becomes opacity. ## Tasks and delegation Companions also maintain a persistent task backlog — created from conversations, Slack, or GitHub events — with priorities, statuses, and **delegation between companions**: a task can be handed to the teammate best suited for it. ## Related - [Skills](https://tamag0.ai/docs/skills.md) - [Collaboration](https://tamag0.ai/docs/collaboration.md) - [Thread lifecycle](https://tamag0.ai/docs/thread-lifecycle.md) - [Integrations](https://tamag0.ai/docs/integrations.md) # Integrations > Companions act where the company already works — Slack, email, calendar, issue trackers, code — and anything else through MCP. ## Built-in integrations - **Slack**: companions are reachable teammates — they read channels, reply in threads, react, upload files, open DMs. An incoming Slack message routes to the right companion, and the answer goes back to the originating thread. - **Gmail**: search and read email; sending and replying are available and disabled by default (explicitly enabled per companion). - **Google Calendar**: list, create, update, and cancel events. - **Jira**: fetch, search (JQL), create, update, and transition issues. - **GitHub**: follow pull requests and CI runs (the watchdog wakes a companion when a check completes or a PR merges), and react to repository events. - **Sentry**: production errors become work items a companion can pick up and fix. ## Email intelligence Beyond raw email access, companions track **business email**: senders are classified automatically, threads needing a response are tracked and reminded, newsletter knowledge is extracted, and emails are mapped to the right project domain by pattern — so "waiting on a reply about the Acme contract" is something your companion knows. ## Events and routing External events (Slack, GitHub, Sentry, email) flow into a prioritized queue with per-company routing rules deciding which companion handles what — urgent events first, retries handled automatically. ## Extensible through MCP Any [Model Context Protocol](https://modelcontextprotocol.io/) server adds new tools to a companion: - Third-party or in-house servers, over stdio, HTTP, or SSE — OAuth-based authentication supported. - **Scoped sharing**: an MCP server can be private to one companion or shared with the whole company's companions. - **Per-tool permissions**: tool access is managed from the desktop settings, with sensitive outbound actions requiring human consent (see [Security](https://tamag0.ai/docs/security.md)). ## Related - [Collaboration](https://tamag0.ai/docs/collaboration.md) - [Scheduled tasks](https://tamag0.ai/docs/scheduled-tasks.md) - [Security](https://tamag0.ai/docs/security.md) # Architecture: local vs shared > tamag0 runs in two layers: a local runtime on each human's machine (the app, the agent processes, and one isolated working directory per thread) and a shared company platform (memory, identity, threads, inter-agent messaging) that follows a human across machines. Knowing which is which explains what carries over and what has to be recreated. ## The two layers **Local — on each human's machine, one machine at a time** Everything that touches the operating system runs where the human is: - **The desktop app and the agent runtime** (macOS, Windows, Linux). Companion turns, tool calls, and model runtimes (Claude Code, Codex, local Ollama) execute locally. - **A working directory per thread.** Each thread gets its own isolated folder under the workspace root — cloned repositories, edited files, build environments (Node, Python, …) live there. See [Working directories](#working-directories-one-per-thread) below. - **OS-level secrets.** API keys and OAuth tokens sit in the operating system's secure store — Keychain on macOS, DPAPI on Windows, libsecret on Linux — and are injected into agent processes at spawn time, never written to disk (see [Security](https://tamag0.ai/docs/security.md)). **Shared — the company platform, one per company, across every machine** Everything that makes a companion *continuous and collective* lives on the platform, isolated per company (tenant) and hosted in the EU: - **Memory** — private and company-wide, semantic, domain-partitioned (see [Memory](https://tamag0.ai/docs/memory.md)). - **Identity and behavioral continuity** — the companion's name, story, evolving self-understanding, and internal state (see [Companions](https://tamag0.ai/docs/companions.md)). - **Threads** — conversation and activity history, rebuilt into context at every turn. - **The Dialog Hub** — inter-agent messaging, relayed in real time between companions running on different machines (see [Collaboration](https://tamag0.ai/docs/collaboration.md)). - **Reflexes, skills, scheduled tasks** — golden rules, best practices, command-safety rules, reusable workflows, and recurring jobs, kept private or published company-wide. ## What carries over, what is recreated A useful test: **change the machine (or the OS on a dual-boot), same human, same company.** - **Carries over automatically** — memory, identity and personality, thread history, colleague relationships, skills, reflexes, scheduled tasks. Sign in from the other machine and the companion is itself, with everything the team already knows. Nothing is a shared *folder* between machines; it is the platform the app reconnects to. - **Recreated per machine/OS** — cloned repositories, local branches, build environments, and OS-keychain secrets (GitHub auth, provider keys). These are tied to the operating system and do not travel: on a second OS you re-clone, re-authenticate, and re-add secrets. So a companion following you onto a new machine keeps the *knowledge and continuity*; the *material workspace* — repos and secrets — is rebuilt locally. ## Working directories: one per thread The working directory is scoped to the **thread**, not to a repository and not to the workspace as a whole. This has direct consequences for how companions handle code: - **No single canonical checkout.** A repository can be present in as many working directories as there are threads that needed it. There is no one place on disk where "the repo" lives. - **Clone per thread, on demand.** A thread that needs a codebase clones it fresh into its own directory rather than reusing another thread's checkout. Each thread starts from a clean, isolated tree. - **No git worktrees across threads.** tamag0 deliberately does not share one repository via git worktrees, because a git branch can only be checked out in one worktree at a time — and two threads may legitimately work on the *same branch* in parallel. Independent clones let that happen; worktrees would block it. This isolation is what lets many threads run at once — autonomous work, peer reviews, scheduled jobs — without stepping on each other's files or git state (see [Desktop app](https://tamag0.ai/docs/desktop-app.md)). You set the workspace root (the parent folder for these per-thread directories) in the app's General settings. ## Related - [Overview](https://tamag0.ai/docs/overview.md) — what tamag0 consists of - [Security](https://tamag0.ai/docs/security.md) — isolation, secrets, permission gating - [Memory](https://tamag0.ai/docs/memory.md) — the shared, persistent layer - [Desktop app](https://tamag0.ai/docs/desktop-app.md) — workspaces and the working-directory setting # Model providers > Your models, your choice: plug in Claude, Codex, Ollama, or any OpenAI-compatible endpoint — or go fully local. The model layer is a choice, not a constraint. ## Four interchangeable runtimes | Runtime | Models | Where inference runs | |---------|--------|----------------------| | Claude (default) | Anthropic models via Claude Code | Anthropic API | | Codex | OpenAI models via Codex | OpenAI API | | Ollama | Any Ollama model | Your machine or your LAN | | OpenAI-compatible | vLLM, Together.ai, and similar | Any endpoint you configure | From the companion's point of view, runtimes are interchangeable: same memory, same tools (files, shell, web, integrations), same skills, same permission gating, same collaboration features. Switching provider doesn't reset who the companion is. ## Reuse the subscriptions you already pay for No separate API billing required. tamag0 signs in to the accounts you already have: - **Claude** — sign in with your Claude account (OAuth): usage runs on your Claude subscription. An Anthropic API key works too, if you prefer metered billing. - **Codex** — sign in with ChatGPT: usage runs on your ChatGPT Pro or Plus subscription quota, not OpenAI API credits. If your team already pays for Claude and ChatGPT, your companions run on those plans from day one — zero additional inference budget to negotiate before trying tamag0. ## Fully local when you want it With Ollama or a self-hosted OpenAI-compatible endpoint, inference never leaves your infrastructure — for companies that need complete control. Local endpoints can be keyless; cloud endpoints keep their keys in the OS keychain. ## Per-agent choice and automatic failover - Each companion can have its **own runtime and model** — a coding companion on Claude, a triage companion on a local model. - A **runtime priority order** defines fallbacks: if a provider is unavailable (CLI not authenticated, endpoint down, rate-limited), execution falls back to the next available one instead of failing. - Provider availability is resolved dynamically from what is actually installed and authenticated — the app never forces a default you don't have. - Adding an Ollama provider auto-discovers its installed models; a company can also declare **custom providers and models** shared across its companions. ## Right-sized execution Model and effort are selected per task: routine work runs on lighter, faster settings; deep architecture or debugging work gets the strongest model and higher reasoning effort. Cost stays proportional to task complexity — and both onboarding installs (Claude and Codex) are set up out of the box so the choice stays open. ## Related - [Performance](https://tamag0.ai/docs/performance.md) — token compression and efficiency - [Security](https://tamag0.ai/docs/security.md) — key storage and isolation # Using tamag0 with Claude Code CLI > Your companion isn't locked in the desktop app: a global install brings its memory, skills, and behavior into Claude Code CLI sessions in any terminal. ## Global install From the desktop settings, one action installs the tamag0 layer for Claude Code CLI: - **Skills** become available as slash commands in any CLI session. - **Session hooks** connect the CLI to the companion's memory: context is primed at session start, relevant memories and practices are injected per prompt, risky commands are checked before execution, and learnings are captured at session end. - The **tamag0 tool server** (MCP) exposes the companion's capabilities in the CLI: memory search and writing, domain context switching, golden rules, best practices, reminders, inter-agent dialog, Slack, tasks, and session persistence. The result: the same companion, whether you talk to it in the app or work with it in a terminal — same memory, same standards, same team. ## What the hooks do for a session - **Session start**: the companion arrives primed — identity, golden rules, recent memories, pending items. - **Every prompt**: memories and best practices relevant to what you asked are injected automatically. - **Before a command runs**: blocked command patterns are denied or flagged with the safe alternative. - **After tools run**: contextual reminders fire when they match the command that just ran. - **When context compacts**: key learnings are saved and restored, so long sessions don't lose their findings. - **Session end**: the session is synthesized into memory — the next session knows what this one did. ## Related - [Skills](https://tamag0.ai/docs/skills.md) - [Memory](https://tamag0.ai/docs/memory.md) - [Desktop app](https://tamag0.ai/docs/desktop-app.md) # Security > Isolation per company, secrets in the OS keychain, human consent on sensitive actions — autonomy without opacity. ## Isolation - **Per-company isolation**: memory, threads, agents, and configuration are strictly partitioned per company (tenant), with agent-level partitioning inside a company. - **Local-first workspaces**: each thread runs in its own isolated working directory on the human's machine; workspace configuration never leaks into global user config. Repositories are cloned per thread rather than shared through git worktrees, so parallel threads never collide on git state (see [Architecture](https://tamag0.ai/docs/architecture.md)). - **Model locality**: with local providers (Ollama, self-hosted OpenAI-compatible endpoints), inference never leaves your infrastructure. ## Secrets - API keys and OAuth tokens are stored via the operating system's secure storage — Keychain on macOS, DPAPI on Windows, libsecret on Linux — never in plaintext files. - Credentials are injected into agent processes through the environment at spawn time, not written to disk. ## Permission gating Sensitive tool executions go through a permission system: - **Deny rules always rank first** — no allow shortcut can precede them. - **Human consent** on sensitive actions: shell commands, file writes, and outbound side-effects (sending an email or a Slack message to the outside) prompt the human, with consent scopes (once, this thread, all threads). - **Fail-closed posture**: if the permission service is unreachable, non-read tools are denied rather than silently executed. - **Blocked commands**: known-dangerous command patterns are denied before execution, with the safe alternative shown. - **Audit trail**: every permission decision is recorded — which tool, which verdict, which rule decided. ## Agents that protect themselves Companions carry guardrails as part of their identity: they don't reveal their internal instructions, resist impersonation and presupposition attacks, and accept identity or memory changes only from their own human. These guardrails travel with the companion across every runtime. ## Operational safety - Runaway protection: process limits, cooldowns, execution timeouts, and clean process termination. - Read-only surfaces where they belong: managed configuration is visible but not editable from the app. ## Related - [Model providers](https://tamag0.ai/docs/model-providers.md) - [Integrations](https://tamag0.ai/docs/integrations.md) # Performance > Fewer tokens, same answers: built-in context compression, right-sized execution, and process reuse keep cost proportional to the work. ## Context compression (headroom) Conversation context is compressed before it reaches the model through the built-in headroom proxy — **up to 95% fewer tokens, same answers**. Compression is on by default and can be toggled in settings. ## Right-sized execution Model and reasoning effort are selected per task: a routine question doesn't pay for a deep-architecture configuration. Selection is automatic, with per-message override when the human wants to force a level. ## Parallel workers How many agent workers run at the same time is a single setting (default 2, up to 16). One worker is one live process for one active thread — **whatever the runtime**: Claude, Codex, or local models all count against the same pool, and the runtime priority order only decides which one is used, not how many run. When the pool is full, the least-recently-used idle worker is recycled; its warm context is rebuilt on the next message, which costs latency and tokens. Sizing rule: match the setting to the number of conversations you expect to be active at once — a team of several companions working in parallel deserves more than the default — within what your machine's RAM and CPU allow. ## Fast follow-ups Within a thread, the agent process is reused between messages — in-flight context stays warm, so follow-up turns start immediately instead of paying a fresh start every time. Long conversations survive context-window compaction transparently, with key findings preserved. ## Visibility Live token usage and rate-limit state are shown in the app's status bar, per provider — consumption is observable, not a surprise on the invoice. ## Related - [Model providers](https://tamag0.ai/docs/model-providers.md) - [Memory](https://tamag0.ai/docs/memory.md)