5ab16b836a
Correcting the previous commit's reasoning. It claimed the difference between
this file and what production published was inert — a defaulted `webSearch:
false` and a reordered skills list. That was based on comparing the file
against the LIVE row in agent_definitions. The live row was the wrong thing to
compare against: Snapshot compares against the stored v1 in
definition_versions, and those two had diverged.
Read from production directly, v1 as published carries two skills:
skills:
- anomaly-detection
- operational-risk
and the live row carries three, with activity-analysis added. So a skill was
added to this agent after v1 was published, in place, without the version being
raised — the exact silent rewrite this branch exists to stop. It is a genuine
change of behaviour: an agent with a third skill answers differently from one
with two.
So the version is raised rather than the file being bent to match. v1 keeps
what was approved; the current definition, which is what production has been
serving, becomes v2. The earlier alignment of field order and `webSearch:
false` is kept — that part WAS serialisation, and matching it keeps future
imports quiet.
Production has three agents with version rows at all, so two others may hold
the same kind of drift. They did not conflict on this import, which means their
live rows still match what was published; it does not mean nobody edited them.
The image ships agents/, so this file only reaches production on the next
image build. Any build from main at or after this commit carries it; a build
from an older tree will fail the import again, by design.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJvibeSc1JYXjatankqM1g
Agent specs
The published agent definitions this deployment ships, one file each, as §7
describes: "Adding an agent is a data change." Nothing in internal/runtime
knows any of these files exist.
Where these came from
They are the nine agents in krow-demo/src/agents/, which is where the product
authored them and where they still live for the frontend's registry. These are
not copies — they are the same definitions with two blocks the frontend has no
field for:
tools:— the registry names this agent may call. The frontend has no tool layer, so its specs carry none; the backend has seventeen tools and an agent that names none of them can only talk.sources:— the knowledge corpora it may retrieve from. Namedsourcesrather thanknowledgebecause the shipped product already usesknowledge:for an author's notes. See the note onruntime.Agent.KnowledgeSources; the collision is flagged, not settled.
An unknown frontmatter key is ignored by both parsers, so these files still load in the frontend registry unchanged.
Publishing
make import-agents ORG=<slug>
Idempotent: re-running updates the definitions in place rather than duplicating them.
The rule these files exist to keep
If adding an agent here ever requires editing code in internal/runtime, that
is a missing platform capability, not a special case. §7 and I6 both say so, and
the loop has no branch that asks which agent it is running.