Rebuilding a quarterly check-in as a reflection agent

The reframe

The original plan treated the check-in as a data problem: pull a person's activity telemetry and summarize their quarter back to them. I rejected that design. A system that watches you and then tells you what you did is a surveillance tool, whatever the intent behind it, and people read it that way immediately.

I inverted the direction. The agent helps the person reflect and assemble their own account of the quarter. It is a reflection tool, not monitoring, and not scoring. That decision set what I refused to build: there is no telemetry ingestion, and the agent produces no evaluative output of any kind.

I set that framing explicitly before recruiting a single pilot participant, because for a tool like this the framing is the product. If the first pilot invitation had been vague about whether this was measurement, no amount of later design work would have recovered the trust.

Skill as brain, agent as home

The intelligence lives in an agent skill and the relationship lives in an agent. The skill encodes how a good reflection conversation runs. The agent is the home base where the check-in happens, and a Slack agent carries the same skill into the flow of work. The design moved through three documents: a PRD that made the case for the reframe, an alternative build spec that developed a competing approach far enough to compare honestly, and a technical spec for the design I committed to.

Building the skill meant turning the trust framing into rules the system enforces rather than promises. Sources are opted in one by one, and the skill discovers what a person's connected tools actually show at runtime instead of keeping stored lists about them. Every observation cites its evidence inline, so the person can verify any line in about thirty seconds. The skill will not grade, rank, or compare people to their peers, and it declines even when the person asks to be rated.

Memory is plain markdown in a folder the person owns on their own machine, readable and editable in any tool, with a corrections log the agent treats as standing instruction. The skill is also isolated from the system of record: every output is a draft, and the person moves their reflection into the official check-in themselves. Onboarding ends by producing a first reflection on the person's own recent work rather than a configuration screen, because the fastest way to show what the tool is for is to hand someone their own story.

• Every output is a draft; the person publishes, never the agent
• Sources are opted in one by one, at the source level
• Every observation cites evidence the person can check
• No grading, no rankings, no peer comparisons, even on request
• Private messages are never quoted, and personal life is filtered out

The launch sequence

I built the launch order around one failure mode: a person getting a notification from a system they had never heard of. The automations shipped first, disabled, so I could test the plumbing while nothing could fire. Only then did the app open to all employees, followed by the comms and documentation that explained what it was and what it was not.

Managers went first and had results before the employee rollout began, so the people most likely to field questions had seen the output before their teams did. None of this was technically hard. It was sequencing, and sequencing is where people tools fail: a premature notification reads as surveillance no matter how carefully the product was framed, so the rollout order was part of the trust design.

The unglamorous half

Replacing a people process the whole company uses means the current one has to keep working while you build its successor. Nobody grants a maintenance freeze on performance cycles, so I owned the legacy check-in system and its live quarterly cycle in parallel with the rebuild.

That ownership was concrete: approval logic, notification automation, fixes for a broken submit button and a broken manager team view, and a bulk data remediation when bad records accumulated in the base. Each item was small on its own, and together they were the difference between a process people could rely on and one they had to work around.

This work bought the rebuild its credibility. A team that lets the current system decay while promising a better one teaches the company to distrust both, so keeping the old check-in reliable was part of the argument that the new one would be.

• Approval logic for the existing check-in flow
• Notification automation for the live cycle
• Submit button bug fix
• Manager team view bug fix
• Bulk data remediation in the production base

What transfers

When you put AI into a people process, the framing is the product, and it has to be set before anyone touches the tool. The same capability, an agent that can assemble an account of someone's quarter, becomes a reflection tool or a surveillance tool depending on who directs it and who owns the output. That is a design decision that has to come first, because it determines what you build and what you refuse to build.

Three smaller lessons held up. Enforce trust in the architecture rather than in the copy: opt-in sources, draft-only output, and evidence the person can check do more work than any privacy statement. Ship the dangerous parts disabled, because an automation that exists but cannot fire lets you test plumbing without spending anyone's trust. And keep the old system healthy while you replace it, because for a required process, reliability is the first trust signal, and the new tool inherits whatever reputation the old one earned.