Ihza MahendraResume
Back to Evaluation & calibration
Evaluation & calibration

Running narrative that compounds across everything a person does

A continuously updated story of how one person is actually progressing, built from every task, conversation, and submission they complete, so the system remembers the pattern instead of re-reading them from scratch every time.

What it is

A running, per-person narrative that stays up to date as someone works. Every time they finish something, a conversation, a piece of work, an understanding check, a live coaching session, a presentation, one entry gets added to their story. Over time, those entries build into a moving picture: what this person actually understood, what they needed to be walked through, what they applied successfully later on their own, and where the same gap keeps showing up.

What it's for

Most systems read a person one event at a time: pass, fail, next. To actually coach someone well, a system needs the running story across all their work: not just whether they passed this task, but whether they passed it the same way they usually do, or the same way they usually stall. This narrative is that story. It's what the next conversation, the next deeper review, and the end-of-project review all read before they respond, so nothing has to start over and re-learn who this person is from zero every time.

How it was built

One central, append-only record per person, written to across everything they do. Every completed task or conversation adds an entry: what just happened, what it suggests about this person, and what should carry forward to the next thing they do. The entry is only written after that task's own result is in, so it's grounded in a real outcome, not a guess. Other parts of the system (deeper skill reviews, end-of-project reviews, the AI team itself) pull the most recent entries to ground their next response. The key design choice is that each entry references the one before it, so the story stays coherent across weeks instead of resetting every time the person comes back.

My role

Tech lead. Owned the compounding-handoff design, the per-completion write schema, and the read paths the rest of the system uses to ground its next decision.

Built with
PythonTemporalPostgresFastAPI

Want the full technical depth, the tradeoffs, what broke, what I'd do differently? Ask the agent about this project.