03 — Why these products
Each one answered
a requirement we already had.
The loop above needs six specific things to exist. Every sponsor below is named by the requirement it satisfied. Remove any one and something concrete stops working.
"To evolve, the agent must know when it was wrong — verifiably, against a citable source."
→Senso
A verified knowledge base that returns a grounded answer, a verbatim citation, and a relevance score for every turn. That is the correctness oracle. Every fitness number in this project traces back to a Senso answer.
The bonus we did not plan for: the escalation policy lives in the knowledge base too. Editing the KB changes when the agent may transfer a caller — with zero code change.
"The model that speaks has to be the model that learns."
→Pioneer
Plainly: Pioneer is the model behind the agent's voice. Every sentence
the caller hears is generated by gpt-5.4-mini served from Pioneer, over an
OpenAI-compatible endpoint. It is a one-line base-URL change, and it sits on the hot path of every
single call.
That placement is the entire point. Pioneer's product is adaptive inference:
it mines your live production failures, trains a specialist on them, and promotes the
improved checkpoint behind the same endpoint. That only means something if the failures being mined
are real calls it actually served. Ours are. Had we scored with Pioneer but served with someone
else, the traces would be a synthetic dataset wearing a production label.
So there are two layers learning from one signal: the workflow
graph, which evolves in minutes, and the model weights, which evolve over hours. Honest:
the fine-tune takes roughly 6 hours. Traces are submitted and the job is kicked. The weight layer is
training, not trained.
"A patch is only worth keeping if it can find the next failure that looks like it — structurally, not topically."
→Actian VectorAI
Every survivor is stored keyed on a failure-signature embedding containing failure type, node role, tool available, tool invoked, value asserted. No utterance. No product. No vertical. Signature-only embedding is exactly what makes the cross-vertical transfer work.
If domain text leaked in, retrieval would key on topic and transfer would silently stop working while still looking fine.
"You cannot evolve what you cannot read, write, publish and version."
→Dograh
A React Flow workflow graph exposed over REST, with real versioning and headless text sessions. We read the graph, mutate a node, write it back and publish. Gen-0 through gen-4 coexist as real versions — that is what the diff view is showing.
Publishing is not optional: the text-chat runtime runs the draft while the UI shows the published version, so apply_and_publish does both.
"Something is deciding what ships to production. Who reviews it?"
→Guild
Plainly: Guild is where the reviewer lives. One component in this
system holds real power — the validator, which decides whether a patch reaches the live graph. On a
laptop that is an unversioned function whose reasoning vanishes the moment it returns. We published it
on Guild as a deployed, semver-versioned agent with a server-validated output schema and a full
execution trace.
So "which validator approved this patch, and what did it actually think" resolves
to an immutable build id and a replayable trace of llm_start /
llm_done spans — not to a line in a log file. Our Python pins the published
version rather than tracking HEAD, so a verdict is always attributable to a specific build.
Then it earned its keep as a second opinion. On real
generation-1 candidate wp_b4da9382, our local gate killed it on 4
regressions by replaying history. Guild's hosted validator — a different model family, never executing
the graph, reasoning from the diff alone — independently returned reject and
named the exact persona that would break. Two gates, two mechanisms, one verdict.
"A dashboard we demo live has to actually work."
→Replay.io
21 journeys explored against the dashboard over an outbound-only tunnel. 0 open bugs at submission. One genuine fix landed: the graph-diff view defaulted to the highest generation, and since most generations correctly kill all three candidates, the load-bearing visual showed an empty state most of the time.
Honest: 18 of 21 runs show failed, for harness reasons. The dashboard polls every 2s and replaces DOM nodes, so an automated driver can resolve an element and then click a detached one. A human never sees it. Effective coverage is 3 completed runs plus the exploration pass — not all 21.
The boundary of the hypothesis space
The system mutates within four operators — append_constraint,
add_tool_requirement, rewrite_instruction,
change_transition. It cannot invent a new node type.
Within that space, hypothesis generation is autonomous. We wrote the fitness function
and the operators. We did not write the rules they produced.
We wrote the fitness function.
We did not write the rule it discovered.
