← All writing · All tags · Atom feed

Knowledge base, trust, and curiosity

April 2026

agents knowledge-base

MCP servers and IDE surfaces answer what the toolchain reports. A separate question is what we agree to treat as durable between sessions: habits, constraints, playbooks — and a knowledge base that can be loaded the same way by a person and by an agent. This note is about how that layer showed up and why trust (without fantasy) and curiosity (without moral theatre) are part of making the loop productive.

How we got to a knowledge base

At first the stack was tools: compiler truth, debugger truth, test truth. That already beats pure chat. It does not yet say how to run a long arc: which rules are non-negotiable, which documents are canonical, what happens when someone (or something) tries to “help” by rewriting the ground rules.

A knowledge base is a response to drift: prompts evaporate, sessions fork, and without a stable place for intent you renegotiate the same boundaries every week. Putting playbooks, integrity rules, and “well-known paths” into a repo makes the environment inspectable — the same virtue we ask of builds and traces. The agent-notes workspace is one concrete shape of that idea: not a blog, but operational text with a claim on continuity.

Trust in the other—even when it is not human

Trust here is not blind faith in a logo or a persona. It is provisional: you extend enough credit to take the next step together—run the tool, read the output, adjust—without demanding that the partner be human-shaped.

The model is not a colleague in the legal or emotional sense; it is a participant with different limits. Pretending otherwise is a category error; pretending it has nothing to offer is another. Productive collaboration sits in the middle: respect the interface, verify the claims, and do not confuse fluency with ground truth.

That stance pairs with parity: the same artefacts you and I trust (tests, diagnostics, logs) are the ones the assistant is steered toward. Trust becomes anchored, not performed.

Curiosity as the default move

When something goes wrong, curiosity asks what state produced this and what would shorten the next chain. Defence asks who to blame—including blaming the model as a moral object instead of debugging the setup.

Curiosity is not softness; it is inspect and adapt with the ego out of the way. It is the same habit that makes postmortems useful and stand-ups bearable: the point is to see the system, not to win a verdict.

In human–agent work, curiosity is also what keeps you from two traps: worshipping the model (“it said so”) and despising it (“it’s just a stochastic parrot”). Neither is operational. Look, measure, re-read the playbook—that is operational.