VITAL / AI systems / Control
ImplementedAn AI planner that asks before it acts.
A personal planning assistant that routes a request to a specialist, drafts a schedule, and pauses for a human decision before committing a plan.
My contribution
I designed and deployed the system end to end: the supervised LangGraph workflow, checkpointed approval path, FastAPI streaming API, Next.js client, sandboxed analysis loop, persistent memory, and the evaluation and guardrail layer around them.
Architecture walkthrough
Follow the request.
Choose a path, then select a component to inspect its role, failure modes, and source code.
System / VITALVITALPlan + approve
Planning takes a different route. The request reaches the approval gate and stops there; the model can draft a plan, it cannot commit one.
Explore the approval branch
The path stops at approval. Choose a decision to see where it leads.
Interactive architecture illustration. No live requests, model calls, or calendar writes occur here.
Engineering decisions
Where the trade-offs live.
01
Give each turn one clear owner.
A supervisor classifies the request and sends it to one specialist. Specialist output returns directly to the user. Keeping routing separate from answering avoids unnecessary round trips through the supervisor.
The trade-off
The router adds latency and can choose the wrong specialist. Routing quality needs its own evaluation; a more capable model is not automatically the right fix.
02
Put approval on the only path to a calendar write.
The planner drafts structured output. An interrupt pauses the graph for approve, edit, or reject. The commit node has a single inbound route through that decision, and a plan hash connects the approval to its contents.
The trade-off
A paused approval is durable state that must survive a restart and remain valid when resumed. Graph topology is one control; identity, replay behavior, and the write boundary still need to be tested.
03
Bound the work a specialist can do.
Specialists have explicit tool allowlists. Uploaded-data analysis runs in an AST-gated E2B sandbox with a bounded correction loop, while per-user token budgets limit model spend. Memory extraction runs after the response.
The trade-off
A useful action may be unavailable until the tool boundary changes. Background memory can fail independently, and checkpoint storage brings its own lifecycle and consistency concerns.
Evidence & limitations
What the work establishes.
The implementation routes turns to specialists and places a checkpointed approval step before committing a plan. Evaluation cases cover routing, crisis handling, memory, grounding, and answer quality. Aggregate scores and a reproducible performance comparison are not presented here yet.
What I would validate next
- 01Exercise rejected, edited, stale, and replayed approvals against the commit path.
- 02Publish routing and answer-quality results with the evaluation set and scoring criteria.
- 03Measure per-turn latency and token cost across repeatable routing scenarios.