The first run of the new importagents against production refused, which is the guard working rather than a fault: version 1 of activity-agent was already published and said something different from the file this repository ships. The difference is inert. Production's copy adds `webSearch: false`, which is exactly what the parser defaults to when the key is absent (agent.go:471 reads `data["webSearch"] == true`), and lists the same three skills in a different order. Both forms parse to the identical agent — 2 tools, 0 sources, 3 skills, confirmed by running the importer's own dry-run over each. What happened is a round trip: somebody edited this agent in the UI, the editor re-serialised it, and that serialisation is what got snapshotted as v1. The hand-authored file was never the published artefact for this one. So the file is updated to match rather than the version being bumped. Bumping would publish a v2 that differs from v1 only in field order and a defaulted key, which is noise in a history whose whole purpose is to say what changed. This unblocks the import. It does not address the underlying awkwardness: the comparison is textual, so any future UI edit that reformats without changing meaning will block a deploy the same way. Comparing the PARSED definition instead would fix that properly and is the right follow-up — it needs a decision about what counts as semantically equal (skill order, starter order) and should not be rushed in behind a deploy. 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.