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.
여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗
