Project
AI powered personal development platform
- Role
- AI Engineer
- Context
- Client product
- Stack
A commercial product in production: contextual mentor, per area diagnosis, and a 90 day plan the interface renders as an object rather than as text.
The problem
A personal development product talks to users about habits, goals and emotional state. That puts the AI layer on sensitive ground: the same answer that reads as supportive can, in the wrong case, become advice the product has no standing to give.
Beyond content risk there is cost risk. The product sells on a flat subscription, so every cent of inference comes out of the margin. An LLM layer exposed to end users with no ceiling is a bill that grows on its own.
The solution
The AI layer of a mobile personal development product, with a contextual mentor, a per area diagnosis and a 90 day plan that the interface renders as an object instead of text. All of it behind a single call point, with scope guardrails, moderation and a per user cost ceiling.
How a query moves through the system
- 01
Runner
every call comes through here, with no feature exempt.
- 02
Moderation
input is checked before any generation is paid for.
- 03
Context
diagnosis, areas and plan come from the database per user, within a token budget.
- 04
Generation
the answer is requested under a schema, not as free text.
- 05
Validation
the object is checked at the edge before the interface renders it.
Engineering decisions
- 01
Every model call goes through a single point.
- Alternative considered
- Each feature talking to the API directly, with its own client.
- Why
- Moderation, timeout, retry, schema validation, prompt versioning and token accounting become concerns solved once, instead of each feature solving them its own way and drifting apart. The day a guardrail changes, it changes in one place: with a client per feature, it changes in all of them and fails in one.
- What it cost
- Coupling. Every new feature is born inside that layer, and none of them can try a different model or call shape without going through it.
- 02
No vector search: context comes from the database, per user.
- Alternative considered
- Embedding the user history, a vector index and reranking, which is the default path for "give the model context".
- Why
- The corpus that matters to the mentor is the user own data: the diagnosis, the open areas and the plan in progress. Fetching that by identifier in Postgres is exact, auditable and cheaper than embedding and ranking dozens of records that already arrive with the right key. Context assembly runs on a fixed token budget, with an explicit priority order.
- What it cost
- It does not generalise. The day the mentor needs to cite content the user did not write, there is no retrieval layer to reuse, and it will have to be built from scratch.
Outcome
A commercial product sold to a client, with the AI layer running in production.