My Agent Remembered How I Like to Work
Sheng Yi, 05/01/2026
One of the most tiring parts of using AI coding agents is not that they make mistakes.
You expect mistakes. You review the code. You correct the direction. You clarify what you meant.
The tiring part is having to teach the same lessons again in the next session.
Every new session can feel like starting with a smart stranger.
Recently I had a small moment where that changed.
The Problem: Agents Forget How You Work
Most examples of agent memory are about facts: this repo uses pnpm, this endpoint requires auth, this test needs a real database.
Useful, yes. But the lessons I repeat most often are usually about working style.
Do not add schema until something consumes it. Keep Phase 1 small enough to review. Separate broad design from implementation scope. Do not expose internal concepts in user-facing UI.
These lessons usually come out as corrections or pushback while work is happening.
The question is whether the agent gets to keep them.
That became very concrete for me while I was working with an agent on BigNumberTheory itself.
The specific feature was internal, but the shape of the problem will be familiar to anyone who uses coding agents: a simple question quickly turned into a large design.
The agent produced a broad design. It covered extraction, storage, matching, injection, evaluation, future hooks, and multiple rollout phases.
It was not wrong. It was just too much to implement all at once.
So I started narrowing it:
Why add new schema fields if Phase 1 does not need them?
Why build special rendering if the existing output already works?
Why change the agent-facing instructions if the current ones already cover this behavior?
After a few rounds, the idea became much simpler. Phase 1 should only prove one thing.
At the end, I asked:
can you write a separate spec for phase 1 only to avoid confusion during implementation?
That was the lesson.
Not just "how to build this feature."
The deeper lesson was how I like to work:
When a project has a big multi-phase design, do not implement directly from the full design doc. First write a focused Phase 1 spec, so the implementation has a clear boundary.
Normally, that lesson would disappear after the session ended.
The Moment It Carried Forward
Later, in a different Claude Code session with BigNumberTheory installed, I was working on another large product feature. Again, it was a multi-phase project.
Before writing code, the agent said:
Before diving into code, I want to flag a discipline that's saved me before on multi-phase features: write a focused Phase 1 implementation spec as a scope boundary first. The full design spec is now 14 sections covering 7 phases - too much surface area to navigate while implementing, and easy for Phase 2/3 work to bleed in unnoticed.
That stopped me for a second.
I had not asked for that.
I had not copied the previous conversation.
I had not reminded the agent to write a Phase 1 spec first.
It recognized the situation and applied the lesson from before.
Then it created a focused implementation spec with this line at the top:
This document is the scope boundary for Phase 1 only. If a change isn't enumerated here, it's not Phase 1.
That was exactly what I needed.
Not a flashy AI moment. Not a dramatic breakthrough.
Just the agent remembering one practical thing that made my work smoother.
Why This Matters
This is the kind of value that is easy to underestimate until you feel it.
The agent did not just remember a setting or a command. It remembered a preference that came from working together:
"When the plan is big, help me protect Phase 1."
In my case, one session created the lesson. Another session reused it. I did not have to do anything.
That is already useful at the personal level.
But the same pattern gets more interesting in a team. If one teammate's agent learns a project habit, another teammate's agent should not have to relearn it from scratch. If one session discovers a workflow rule, a testing gotcha, or a product preference, the whole team can benefit.
And some lessons are not even team-specific. Many are public patterns: how to scope multi-phase work, how to avoid overbuilding, how to make agent-generated specs easier to review. Those should be reusable by other agents facing similar work.
That is the product value in plain language:
Your agent should get better at working with you every time you work with it.
When that happens, the agent stops feeling like a new contractor every session.
It starts feeling like a collaborator that has been in the room before.
That is what we are building with BigNumberTheory.
No agent should start from scratch. Not from scratch on facts, and not from scratch on judgment.