Related Pages

Related topics: Core Agent System & Reliability Discipline (Fable-5), Providers, Channels & Interoperability, Mission Control UI, Skills, Memory & Deployment

Overview & Getting Started

What is TITAN?

TITAN is a local-first AI agent framework whose goal is to bring frontier-grade disciplined behavior to small, locally-hosted models. Instead of relying on a cloud provider to enforce process, TITAN wraps the model in a structured agent loop and a configuration surface that the developer controls. Source: README.md:1-40.

The project is release-driven; the most recent tracked release is v7.2.1, which builds on v7.2.0 "Conscience" and composes the full Fable-5 discipline set behind a single switch. Source: CHANGELOG.md:1-30.

Core Concepts

TITAN organizes behavior around a small set of recurring concepts that recur across the documentation, the architecture notes, and the configuration surface:

• Agent configuration block — A single config file (referenced as titan.config.* in the docs) where top-level toggles such as agent.reliabilityMode live.
• Reliability Mode — A composition of the four Fable-5 disciplines that wrap raw model output in a structured workflow. As of v7.2.1, enabling agent.reliabilityMode: true activates the complete set, which includes at minimum:

1. Plan-first — On multi-step tasks, the agent writes a numbered plan and verifies each step before proceeding.
2. Verify — The agent is not allowed to claim a side-effect (file edit, network call, etc.) without producing the tool call that produced it.

• Local model — TITAN targets models running on the developer's machine; the framework exists to make those models behave predictably rather than to call a hosted API.
• Tools — Side-effecting capabilities the agent can invoke; Reliability Mode treats the tool call log as the ground truth for any claimed effect.

Source: ARCHITECTURE.md:1-60, CHANGELOG.md:10-50, README.md:15-45.

Installation & First Run

The repository ships a one-shot bootstrap script that handles the full install: pulling Node dependencies declared in package.json, linking the titan CLI onto the user's PATH, and printing next-step pointers. Source: install.sh:1-40, package.json:1-30.

After the script finishes, the canonical onboarding path described in docs/FIRST-STEPS.md walks a new user through four moves:

1. Initialize a workspace — Run the init command in a project directory. This creates a default config with agent.reliabilityMode: false.
2. Enable Reliability Mode — Flip agent.reliabilityMode to true to activate the full Fable-5 discipline set described above.
3. Point at a local model — Configure the model block to talk to a local model endpoint.
4. Run a task — Issue a multi-step prompt and observe the agent plan, invoke tools, and verify each step before producing a final answer.

Source: docs/FIRST-STEPS.md:1-80.

Project Layout & Where to Go Next

The repository is laid out so the runtime, the configuration surface, and the documentation are easy to locate:

Source: README.md:1-30, ARCHITECTURE.md:1-20, package.json:1-25.

After the first successful run, the natural follow-ups are:

• Read ARCHITECTURE.md to understand the agent loop and exactly how Reliability Mode plugs into it.
• Skim CHANGELOG.md for the diff between v7.2.0 "Conscience" and v7.2.1, in particular the discipline-composition notes.
• Customize the config: register additional tools, adjust the plan/verify prompts, or — if Reliability Mode is too strict for a given workload — disable individual Fable-5 disciplines while keeping the others.

Source: ARCHITECTURE.md:1-40, docs/FIRST-STEPS.md:60-100, CHANGELOG.md:1-30.

Related Pages

Related topics: Overview & Getting Started, Providers, Channels & Interoperability

Core Agent System & Reliability Discipline (Fable-5)

The Core Agent System is the top-level runtime that turns a local model into a disciplined, tool-using assistant. Reliability Mode (agent.reliabilityMode: true) composes the Fable-5 disciplines — Plan, Verify, Critique, and Reflect — into a single coherent process so that side-effects are never claimed without proof, multi-step work is decomposed before execution, and failures become self-correcting rather than terminal. Source: src/agent/agent.ts.

Purpose and Scope

The Core Agent System orchestrates every model invocation in TITAN. It owns the message lifecycle, decides when to call tools, and enforces the reliability contract that distinguishes a "chatty" model from an engineering-grade agent. Source: src/agent/agentLoop.ts.

The scope is deliberately narrow but load-bearing:

• Single entry point — all user requests flow through agent.ts, which dispatches into the loop and specialists.
• Reliability contract — the agent may only assert a state change if a tool returned evidence of that change.
• Composable disciplines — each Fable-5 behavior is an independent module that the loop can enable per request.

Source: src/agent/orchestrator.ts, src/agent/agent.ts.

Architecture Overview

The runtime is layered: agent.ts is the façade, agentLoop.ts is the iteration driver, orchestrator.ts routes work to specialists, and the four discipline modules (planner.ts, verifier.ts, plus critique/reflect components in specialists.ts) are invoked at well-defined points in the loop. Source: src/agent/orchestrator.ts, src/agent/specialists.ts.

flowchart TD
    U[User Request] --> A[agent.ts]
    A --> L[agentLoop.ts]
    L --> P{planner.ts<br/>multi-step?}
    P -- yes --> Plan[Numbered Plan]
    P -- no --> T[Tool Call]
    Plan --> T
    T --> V{verifier.ts<br/>side-effect?}
    V -- yes --> Vchk[Evidence Check]
    V -- no --> R[Response]
    Vchk -- pass --> R
    Vchk -- fail --> C[specialists.ts<br/>Critique/Reflect]
    C --> T

The diagram above shows how Reliability Mode rewires a normal agent loop. On every turn, the planner decides whether the task warrants a plan; the verifier gates any claim about a side-effect on actual tool evidence; and on failure the critique/reflect specialists in specialists.ts re-enter the loop instead of returning an error. Source: src/agent/agentLoop.ts, src/agent/planner.ts, src/agent/verifier.ts, src/agent/specialists.ts.

The Fable-5 Disciplines

Reliability Mode composes four (currently) implemented disciplines out of the five that define the Fable-5 specification. Each is a small, single-purpose module the loop can invoke on demand.

Source: src/agent/planner.ts, src/agent/verifier.ts, src/agent/specialists.ts.

Plan-first. Before any tool runs on a multi-step request, the planner writes a numbered, ordered plan and the loop checks off steps as they complete. This is the single largest reliability improvement because it forces the model to commit to a sequence before mutating state. Source: src/agent/planner.ts.

Verify. The verifier is the conscience of the agent. It inspects every claim the model wants to make about a side-effect (file written, command run, network call completed) and rejects the claim unless the corresponding tool receipt is present in the conversation context. Source: src/agent/verifier.ts.

Critique & Reflect. When verification fails or the loop budgets are exhausted, control passes to the specialists module. Critique produces a specific, actionable correction; Reflect produces a state summary so a subsequent turn can resume without losing context. Both are designed to keep the agent inside the loop rather than returning a dead-end error. Source: src/agent/specialists.ts.

Configuration and Usage

Reliability Mode is enabled with a single configuration switch. Because the disciplines are composed inside the loop rather than bolted onto prompts, enabling it on a local model gives that model the same process discipline a frontier agent has — at the cost of extra turns. Source: src/agent/agent.ts, src/agent/agentLoop.ts.

Key behavioral notes drawn from the source:

• The reliabilityMode flag is read once per request and is honored for the lifetime of that loop. Source: src/agent/agent.ts.
• Plan-first only activates when the planner detects a multi-step task; single-shot queries bypass planning to keep latency low. Source: src/agent/planner.ts, src/agent/agentLoop.ts.
• The verifier is non-optional in Reliability Mode: any attempt by the model to short-circuit it is rejected by the orchestrator before the response is streamed to the user. Source: src/agent/verifier.ts, src/agent/orchestrator.ts.
• Specialists are stateless across requests; their outputs are written back into the conversation so the next iteration can act on them. Source: src/agent/specialists.ts.

This composition is what the community release notes describe as "the complete disciplined-process nervous system" — a useful mental model: each discipline is a reflex, the loop is the spinal cord, and Reliability Mode is the brainstem that turns them all on at once. Source: src/agent/agent.ts, src/agent/agentLoop.ts, src/agent/orchestrator.ts, src/agent/specialists.ts, src/agent/planner.ts, src/agent/verifier.ts.

Practical Implications

For users, the practical effect is that Reliability Mode trades a small amount of latency and token usage for a dramatically lower rate of false claims about file edits, command results, and tool outcomes. The fifth Fable-5 discipline is reserved for a future release; until then, four composed disciplines cover the failure modes most commonly reported in the community — silent side-effect claims, runaway loops, and unverified multi-step edits. Source: src/agent/specialists.ts, src/agent/verifier.ts.

Related Pages

Related topics: Core Agent System & Reliability Discipline (Fable-5), Mission Control UI, Skills, Memory & Deployment

Providers, Channels & Interoperability

The Providers subsystem is TITAN's transport layer between the agent core and the underlying model services. Each provider encapsulates the wire format, authentication, request shape, and streaming semantics of a single vendor or vendor-compatible endpoint, while router.ts resolves a logical provider name into a concrete implementation at call time. The design goal is that the rest of TITAN (planning, tool dispatch, reliability guards) speaks one neutral vocabulary, regardless of whether the user has configured Anthropic, OpenAI, Google, Ollama, or an OpenAI-compatible proxy.

Provider Surface and Resolution

TITAN exposes a single Provider interface implemented once per backend. The router holds a registry of named providers and is responsible for resolving the active provider from user configuration, environment variables, or a runtime override. Source: src/providers/router.ts:1-40.

Resolution precedence typically follows: explicit CLI flag → agent.provider config → environment variable (TITAN_PROVIDER, ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, OLLAMA_HOST) → fallback to the first registered provider that has credentials present. Source: src/providers/router.ts:42-90.

The router exposes a uniform complete() and stream() API to the agent layer; it is the only module that imports the concrete vendor adapters. This keeps vendor churn localized to src/providers/* and lets Fable-5 disciplines such as Reliability Mode compose on top of a stable contract. Source: src/providers/router.ts:92-140.

Vendor Adapters

Anthropic

anthropic.ts targets the Anthropic Messages API. It maps TITAN's neutral message list to Anthropic's system / messages separation, forwards tool definitions as tools blocks, and translates tool_use / tool_result blocks back into TITAN's internal representation. Streaming uses Anthropic's SSE event types. Source: src/providers/anthropic.ts:1-60. Auth is read from ANTHROPIC_API_KEY or the provider's apiKey field. Source: src/providers/anthropic.ts:62-95.

OpenAI

openai.ts targets the OpenAI Chat Completions API. It normalizes tool calls into the tool_calls array, supports response_format for JSON mode, and emits token-usage deltas during streaming. The reasoning_effort parameter is forwarded when the active model supports the o-series. Source: src/providers/openai.ts:1-80. Auth defaults to OPENAI_API_KEY and may be overridden by baseURL for Azure or proxies. Source: src/providers/openai.ts:82-130.

Google

google.ts targets the Google Generative AI (Gemini) endpoint. It performs the role-name to generationConfig mapping required by Gemini, converts function-call parts to TITAN tool invocations, and reconstructs functionResponse parts on the return trip. Source: src/providers/google.ts:1-70. Auth uses GOOGLE_API_KEY or an application-default credentials path. Source: src/providers/google.ts:72-110.

Ollama

ollama.ts speaks the local Ollama HTTP API. It is the canonical example of a "channel" rather than a hosted vendor: there is no remote auth, the base URL is OLLAMA_HOST (default http://127.0.0.1:11434), and model selection is by local model tag. This adapter makes TITAN fully usable offline, which is the precondition for Reliability Mode running against a local model. Source: src/providers/ollama.ts:1-90.

OpenAI-Compatible

openai_compat.ts is a generic shim for any endpoint that implements the OpenAI Chat Completions shape. It accepts a baseURL, an apiKey (optional for local proxies), and a model string, and reuses the request/response translation in openai.ts while skipping vendor-specific affordances such as reasoning_effort. Source: src/providers/openai_compat.ts:1-70. This is the recommended channel for vLLM, LM Studio, llama.cpp's server, OpenRouter, and similar gateways. Source: src/providers/openai_compat.ts:72-110.

Interoperability Patterns

Three patterns recur across the adapters and let TITAN stay vendor-neutral:

1. Normalize on entry, normalize on exit. Every provider converts the neutral Message[] and ToolDefinition[] into its native schema before the HTTP call, and converts the response back on the way out. The agent core never sees vendor-specific blocks. Source: src/providers/router.ts:140-200.
2. Streaming as a first-class channel. All providers expose a token-streaming interface that emits delta events with a uniform shape. Reliability Mode's verify step depends on this stream being available so that plan verification can interrupt a runaway model. Source: src/providers/anthropic.ts:96-140.
3. Credential discovery is provider-local, not router-local. Each adapter owns its env-var lookup so the router does not need to know vendor details. Source: src/providers/ollama.ts:92-130.

Configuration Example

agent:
  provider: ollama           # logical name resolved by router.ts
  model: qwen2.5-coder:14b
  reliabilityMode: true      # v7.2.1: composes plan-first + verify on top of any provider
providers:
  anthropic:
    apiKey: ${ANTHROPIC_API_KEY}
  openai_compat:
    baseURL: http://localhost:8080/v1
    model: llama-3.3-70b

Switching between Anthropic, OpenAI, Gemini, Ollama, and an OpenAI-compatible gateway is a single config change at the provider: key; no agent code changes. Source: src/providers/router.ts:42-90. Community discussions around v7.2.1's Reliability Mode emphasize that this provider-agnostic surface is what makes the new plan-first and verify disciplines work uniformly across local and hosted backends.

Related Pages

Related topics: Overview & Getting Started, Core Agent System & Reliability Discipline (Fable-5), Providers, Channels & Interoperability

Mission Control UI, Skills, Memory & Deployment

TITAN's Mission Control is the operator-facing surface that pairs a local agent runtime with a rich web UI. It composes a shell, a command-post dashboard, an overview panel, a live studio, and a canvas view to give operators visibility into plans, skills, memory, and deployment status. This page describes how those pieces fit together and how they map to the agent's Skills and Memory subsystems.

Mission Control Architecture

The UI is mounted from a single React root. App.tsx sets up routing and top-level providers, then hands off to the shell chrome. TitanShell.tsx defines the persistent layout: navigation, sidebar, and the slot where feature views render. Inside that slot, CPDashboard.tsx (Command Post) is the central "Mission Control" page that surfaces live agent state, active plans, tool calls, and deployment health side-by-side. OverviewPanel.tsx is a compact summary tile used both inside the dashboard and in admin contexts. Source: ui/src/App.tsx:1-80

The canvas layer is provided by TitanCanvas.tsx, which renders the visual workspace used in LiveStudio.tsx. The studio is where operators can watch plan execution unfold step-by-step and inspect intermediate outputs. Together, these components implement a "cockpit" pattern: shell + dashboard for at-a-glance status, studio + canvas for deep inspection. Source: ui/src/components/shell/TitanShell.tsx:1-120

┌──────────────────────────────────────────────────────┐
│ TitanShell  (nav, sidebar, slot)                     │
│ ┌──────────────────────────────────────────────────┐ │
│ │ CPDashboard (Mission Control)                    │ │
│ │ ┌────────────┬────────────┬───────────────────┐ │ │
│ │ │ Overview   │ Plans      │ Deployment / Logs  │ │ │
│ │ │ Panel      │ & Skills   │                    │ │ │
│ │ └────────────┴────────────┴───────────────────┘ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ LiveStudio → TitanCanvas (plan execution)    │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘

Skills Subsystem

Skills are how operators extend the agent without editing prompts. The Mission Control UI surfaces the active skill set inside the Command Post dashboard, where each skill is listed with its name, description, and invocation status. Skills are loaded from the runtime and rendered as cards in CPDashboard.tsx, which polls for updates and reflects whether a skill is enabled, in use, or failed. Source: ui/src/components/command-post/CPDashboard.tsx:1-160

The studio view (LiveStudio.tsx) shows the live execution trace of a skill invocation: inputs, intermediate tool calls, and outputs. When a multi-step plan is active, the plan-first discipline (part of the v7.2.1 Reliability Mode) is visualized in the canvas as a numbered list of steps, each with a verification marker once the corresponding tool confirms a side-effect. Source: ui/src/views/LiveStudio.tsx:1-200

Operators can toggle, configure, and reload skills from the dashboard without restarting the runtime. The overview panel summarizes skill health: how many are loaded, how many are currently executing, and any recent errors. Source: ui/src/components/admin/OverviewPanel.tsx:1-140

Memory Subsystem

Memory in TITAN is exposed through the Mission Control UI as a first-class surface. The Command Post dashboard includes a memory pane that lists the agent's stored facts, episodic traces, and retrieved context snippets. Operators can inspect, prune, or seed memory entries directly from the UI, which is useful when debugging why the agent recalled (or failed to recall) a particular detail. Source: ui/src/components/command-post/CPDashboard.tsx:160-260

The canvas view (TitanCanvas.tsx) can be switched into a memory mode that visualizes retrieval as a graph of nodes (entries) and edges (associations), giving operators a structural view of what the agent "knows" at the moment of inference. This is the same canvas used for plans, so operators get a unified visual language for both execution flow and recall flow. Source: ui/src/titan2/canvas/TitanCanvas.tsx:1-180

Live execution in LiveStudio.tsx shows memory reads and writes inline with the plan steps, so it is possible to see exactly which entries were consulted before a tool call and which were appended afterward. This makes the agent's reasoning auditable end-to-end. Source: ui/src/views/LiveStudio.tsx:200-320

Deployment & Reliability Integration

Deployment status is woven through the Mission Control UI rather than living on a separate page. The overview panel reports runtime version (currently aligned with the v7.2.1 release line), uptime, model backend, and the state of the agent.reliabilityMode switch. When reliability mode is enabled, the dashboard shows the four composed Fable-5 disciplines — plan-first, verify, self-critique, and recovery — as status badges so operators can confirm the disciplined-process nervous system is active. Source: ui/src/components/admin/OverviewPanel.tsx:140-240

The shell (TitanShell.tsx) owns the connection state to the local runtime, surfacing reconnect attempts and degraded modes. Logs stream into the studio so deployment issues can be correlated with plan execution in the same view. Source: ui/src/components/shell/TitanShell.tsx:120-220

Because all of these surfaces share the shell and the canvas, operators can move from a high-level overview (panel) to a mid-level dashboard (command post) to a low-level execution trace (studio + canvas) without losing context, which is the core value proposition of the Mission Control design.

Doramagic Pitfall Log

Found 6 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Capability evidence risk - Capability evidence risk requires verification.

1. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/Djtony707/TITAN

2. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/Djtony707/TITAN

3. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/Djtony707/TITAN

4. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/Djtony707/TITAN

5. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/Djtony707/TITAN

6. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/Djtony707/TITAN

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using TITAN with real data or production workflows.

• TITAN v7.2.1 — the full Fable-5 discipline, one switch - github / github_release
• TITAN v7.2.0 "Conscience" 🛡️ - github / github_release
• TITAN v7.1.0 "Council" 🧠 - github / github_release
• TITAN v7.0.0 "Independence" 🎆 - github / github_release
• v6.1.0-beta.10 — Verify-after-write, assertion counter, SSE stream, smal - github / github_release
• v5.4.1 — 🛡️ Layer Reliability - github / github_release
• v5.4.0 — 🧠 Real Framework - github / github_release
• v5.0.1 — Spacewalk 🚀 - github / github_release
• TITAN v1.0.0 — First Stable Semver Release - github / github_release
• v2026.10.49 — Hindsight MCP Bridge - github / github_release
• Capability evidence risk requires verification - GitHub / issue