Anton, chapter 12: Claims, not properties

Two claims sat at the centre of Anton's identity:

It remembers everything I tell it.

It knows how to use all of its tools.

One ordinary exchange on my phone disproved both within the same hour.

That was the shape of the week. Not a difficult bug hunt, but a humbling one.

The features had shipped. The capabilities existed. The tests were green.

Nobody had asked the live system whether the promises were true.

The assistant that could not see its tools

I asked Anton to add something to the family calendar.

It replied that it could not create events directly and offered to set a reminder instead.

Polite. Plausible. Entirely wrong.

The calendar capability existed. I had built and tested it.

The execution trace explained the contradiction.

The family agent had started with only one tool: generic help. None of its real skills were visible.

With no usable capability, the model improvised. It attempted to call a tool named calendar, received an "unknown tool" error, tried again, and eventually produced the best answer it could.

Anton was not refusing to use the calendar.

It was blind and being polite about it.

The skills were alive in the runner the entire time. A boot-order race had populated the agent's tool cache before registration completed, leaving the family agent permanently convinced that almost nothing existed.

A capability can be healthy in one service and absent from the system that needs it.

"Registered" is not the same as "available."

Total recall

While reading the traces, I inspected memory capture.

This was the mechanism that should extract durable facts from ordinary conversations, the engine behind "Anton remembers everything."

It had never succeeded.

Not once.

Roughly 52,000 assistant messages had passed through the system since the feature shipped, and zero had produced captured memory.

A hand-written SQL fragment passed a raw date object into a query parameter. Every capture attempt failed on the same statement.

The error appeared continuously in a log nobody was reading.

The honest description of the feature was not "Anton remembers everything."

It was "Anton has written down nothing."

The gap between those sentences existed for weeks because the system had been tested around the feature rather than through it.

Fixing the first bug reveals the second

Correcting the SQL error did not restore the missing memory.

The backfill intended to recover the lost weeks sent most of its jobs to the dead-letter queue.

My first diagnosis was confident and wrong.

A forensic search suggested the deployed code was stale. I spent time investigating a build problem that did not exist because I had searched a re-export file where the symbol could never appear, whether the fix was present or not.

The check returned a false negative.

I treated it as evidence.

The real failure was in the lock.

The backfill launched more than twenty jobs in a burst. They all competed for one per-user lock. The first job acquired it and began classification. Every other job retried three times over roughly fifteen seconds and exhausted its attempts while the first was still running.

The locking code contained a reasonable assumption: by the time a job retries, the previous holder has usually finished.

That was true for the organic workload it had been designed around, one message arriving at a time.

It was false for a backfill.

The code worked exactly as designed.

The design had never met this load.

Green somewhere

What came out of the week was more than two fixes.

Memory capture gained an end-to-end test through the real database driver rather than a mock that always returned success.

Tool availability became something the live agent had to demonstrate, not something inferred from registration elsewhere.

Because every failure that week had been green somewhere.

The feature was deployed.

The skill was registered.

The mock passed.

The mandate appeared in the system prompt.

Each statement was technically true and operationally irrelevant.

The only thing nobody had done was send a real message to the live box and verify the promise from beginning to end.

It took a screenshot from an actual user to expose both failures.

Earn the claim

I trust the mandate a little less now and the traces considerably more.

That is the right trade.

"Remembers everything" and "uses all its tools" are not properties a system acquires because they appear in a design document.

They are claims.

A claim has to be earned on the live system, through the real path, under the workload it is meant to survive.

And it has to keep earning it every time you repeat it.