TL;DR — Blink AI is built as a thin set of services around a frontier LLM. The architecture is not what makes it work — the prompt engineering, session-state design and evaluation pipeline do. This is an honest walk through the system, including the parts that took longer than expected.
System overview
- Frontend — Next.js web app + React Native mobile app, sharing types and components
- API — Node.js (Fastify), TypeScript strict, Zod for validation
- Database — Postgres with pgvector for memory embeddings
- LLM — Frontier model (Claude / GPT-class) via SDK, with retry and timeout middleware
- Coaching orchestrator — TypeScript service that maintains session state and routes turns
- Evaluation pipeline — offline jobs that score sessions against rubrics
- Observability — Sentry + OpenTelemetry + Grafana
The orchestrator is the product
The LLM is interchangeable; the orchestrator is not. It owns session state (current GROW phase, declared goal, surfaced insights, commitments made), constructs the system prompt for each turn, decides when to escalate to higher-context models, and applies guardrails (safety filters, off-topic redirects, advice-refusal patterns). The model is a function call from the orchestrator’s perspective.
Session state shape
- Phase: one of GOAL | REALITY | OPTIONS | WILL | CLOSING
- Declared goal: short structured summary, updated by the orchestrator after the goal phase
- Reality snapshot: facts the user has surfaced about their current state
- Options generated: choices the user has considered
- Will commitments: concrete next actions, with optional deadlines
- Insight log: moments where the user named something new
This state is persisted per session and re-injected into the system prompt on every turn. The model does not have to remember; it has to read.
Memory isolation
Cross-session memory — what the user worked on last session, what commitments they made — is stored in pgvector with strict tenant + user filtering on every retrieval. A regression test confirms that user A’s queries cannot return user B’s embeddings. The boundary is enforced at the data-access layer, not at the prompt layer.
Evaluation pipeline
- Session sampling — 5–10% of sessions sent to human-coach review (with consent)
- Rubric scoring — each reviewed session scored on rubric (questioning vs telling ratio, phase progression, warmth, alignment with declared goal)
- LLM-as-judge — automated scoring at higher volume, spot-checked against human scores
- Regression set — fixed bank of sessions replayed on every prompt or model change
What took longer than expected
- Resisting helpful-assistant gravity — months of prompt iteration
- Designing session state that the model would actually use, not paraphrase
- Building the evaluation set well enough to drive product decisions
- Getting per-user memory isolation right under a multi-tenant deployment
What was easier than expected
- The actual API surface — small, REST, boring on purpose
- Model swaps — abstracting the LLM behind a single function made A/B testing models a one-line change
- Scaling — token cost is the constraint, not compute
Frequently asked questions
What model does Blink AI use?
A modern frontier LLM (Claude or GPT-class) selected by quality benchmarks against our coaching evaluation set. Model choice is configurable per deployment; the system prompt and orchestration are the durable layer.
How long does a coaching session last?
Typical sessions run 15–45 minutes. The system maintains GROW phase state across the conversation so it can guide pacing — moving the user from Reality to Options, and ultimately to Will, before the session closes.
Working on something similar?
T-Square is an independent software engineering studio. We architect, build and operate production-grade systems for learning, AI and custom software products. Talk to a senior engineer if you’d like a second opinion on your architecture or roadmap.