Fit T. Cent 3.0: Centenarian Coach Multi-Agent

Fit T. Cent 3.0 (the third version of the Fit T. Cent app), also known by its descriptive name Centenarian Coach Multi-Agent. Tagline: Get Fit and Learn Tryin'.

This is a portfolio + course artifact. The live demo is gated to a single admin email, anyone else can join a paid-access waitlist.

Live demo: centenarian-coach-multiagent.witus.online, gated to a single admin email; everyone else can join the access waitlist.

A LangGraph supervisor with specialist subgraphs. You ask one question. A coordinator decides which specialists to consult. Each specialist has its own retrieval store and its own tools. The coordinator weaves the findings into one answer with citations.

---

TL;DR

Most AI coaches use one prompt for everything. This one routes your question to the specialist that actually knows the answer.

The supervisor classifies the user's question, decides which specialists to invoke (one, two, three, or all four), and synthesizes their findings. Each specialist (Nutrition, Workout, Recovery, Corrective Exercise) owns its own retrieval namespace and its own tools. Specialists do not read each other's outputs, the supervisor handles synthesis.

This repo demonstrates three LangGraph patterns: supervisor routing, per-agent retrieval, and state passing across nested subgraphs.

This repo is the artifact for a LangChain Academy Project course (see The course), 6 modules, 28 lessons, with a ~2.5-hour video walkthrough in production. Companion podcast (S1E3, coming after S1E1): coming soon. Sister courses in the same curriculum: Triage Agent (Quickstart tier), Field Reporter (Foundation tier).

---

The problem

A single-agent coach conflates domains. Ask "I slept 5 hours, should I do legs today?" and a single-prompt agent has to be a nutrition expert, a strength training expert, a recovery expert, and a synthesizer all at once. Quality suffers.

The right architecture is a coordinator that knows when to consult one specialist (a pure nutrition question), when to consult two (cross-domain like the legs example), and when to consult all four.

Built originally for CentenarianOS, my personal "live to 100 in good shape" operating system, but architected so the same supervisor + specialist pattern works anywhere. The repo ships an empty kb-fixtures/ directory: bring your own corpus (any domain), seed it, and the routing logic is unchanged.

---

Architecture

graph TD
    USER([User question]) --> SUPERVISOR[Supervisor: classify + route]
    SUPERVISOR -->|nutrition path| NUTRITION[Nutrition specialist]
    SUPERVISOR -->|workout path| WORKOUT[Workout specialist]
    %% all four specialists ship; the supervisor routes to one, two, three, or all four
    SUPERVISOR -->|recovery path| RECOVERY[Recovery specialist]
    SUPERVISOR -->|corrective path| CORRECTIVE[Corrective Exercise specialist]
    NUTRITION --> SYNTHESIZE[Synthesize answer]
    WORKOUT --> SYNTHESIZE
    RECOVERY --> SYNTHESIZE
    CORRECTIVE --> SYNTHESIZE
    SYNTHESIZE --> ANSWER([Final answer with citations])

Each specialist is itself a small graph:

graph TD
    IN([Sub-question]) --> RETRIEVE[Retrieve from own pgvector namespace]
    RETRIEVE --> TOOLS{Need tools?}
    TOOLS -->|yes| TOOLCALL[Call tools]
    TOOLS -->|no| ANSWER
    TOOLCALL --> ANSWER[Compose finding with citations]
    ANSWER --> VERIFY[Verify citation coverage]
    VERIFY -->|unsupported claims| REVISE[Revise once: ground or cut]
    VERIFY -->|clean| OUT
    REVISE --> OUT([Specialist finding])

The verify step is a second, temperature-0 model call that checks every substantive claim in the draft against the retrieved sources and tool results (the same cite-or-drop rule the compose prompt carries). If it finds unsupported claims, the composer gets exactly one revision pass (ground each claim or cut it) and the result ships with citationCheck telemetry on the finding. A verifier failure never blocks the answer; it is recorded as verifierError instead.

---

The three patterns

This repo demonstrates three LangGraph patterns. Each has a companion lesson under /docs/lessons/.

1. Supervisor routing

A typed routing decision before any specialist runs. The supervisor returns a RoutingDecision, which specialists to consult, the primary one, an optional rewritten sub-question per specialist, and a rationale. It is produced with a Zod schema via withStructuredOutput, so an invalid route is unrepresentable.

type Agent = 'nutrition' | 'workout' | 'recovery' | 'corrective';

type RoutingDecision = {
  agents: Agent[];                          // specialists to consult
  primaryAgent: Agent;                      // the most relevant one
  subQuestions: Partial<Record<Agent, string>>;
  rationale: string;
};

The rationale field forces the supervisor to justify its decision in the trace. If routing is wrong, you can see why in seconds.

Full supervisor: src/agents/supervisor/

2. Per-agent retrieval

Each specialist has its own pgvector namespace. Nutrition does not see workout docs. Workout does not see recovery docs. This is the difference between four specialists and one generalist with a fancy prompt.

This is the beginning of the README. Read the rest at the original. Read the full README ↗