The idea
Extra has a rare structural advantage: the entire system is defined in one declarative YAML file. That means an improvement to the system is just a small, human-readable diff.
This opens the door to a capability that could be a real game changer: systems that improve themselves through pull requests.
Why this changes the game
In platforms where agents are defined in code, "a system that improves itself" means code rewriting code: opaque, scary, and something no serious organization would approve. In Extra, thanks to the declarative definition, an improvement is a 5-line YAML diff that a human reads in ten seconds, understands exactly what will change, and decides whether to merge. The same review process all code goes through.
This turns Extra from "another framework for building agents" into a platform where the systems built on it get better on their own over time, with full human control at every step. It's a capability that grows directly out of the product's declarative DNA, and one that is very hard to offer cleanly any other way.
The loop
- Capture feedback. A 👍/👎 button in the chat widget, stored with the conversation.
- Record traces. Per-request routing and tool traces (already planned on the roadmap).
- Propose. A periodic "improver" job reviews 👎 conversations, finds patterns ("12 billing questions were routed to the returns agent") and drafts a small YAML or prompt diff.
- Verify by replay. Re-run the failed conversations against the patched YAML and confirm routing and answers improve, and nothing else regresses.
- Deliver as a PR. A human reviews a short diff and merges, guarded by the regular CI checks.
Because the proposal is a reviewable diff, not opaque fine-tuning or self-modifying code, a human stays in control at every step.
Proposed first step (small, standalone PR)
None of the above is possible without feedback data, so I would start with just:
- 👍/👎 buttons on assistant messages in the widget
- persisted alongside the conversation in
agent_manager (SQLite)
- exposed in the conversations API
This is valuable on its own (analytics on answer quality) even if the rest never happens.
If this direction sounds right, I'm happy to open the first PR. Also fine if you'd rather scope it differently, treating this issue as a discussion starter.
The idea
Extra has a rare structural advantage: the entire system is defined in one declarative YAML file. That means an improvement to the system is just a small, human-readable diff.
This opens the door to a capability that could be a real game changer: systems that improve themselves through pull requests.
Why this changes the game
In platforms where agents are defined in code, "a system that improves itself" means code rewriting code: opaque, scary, and something no serious organization would approve. In Extra, thanks to the declarative definition, an improvement is a 5-line YAML diff that a human reads in ten seconds, understands exactly what will change, and decides whether to merge. The same review process all code goes through.
This turns Extra from "another framework for building agents" into a platform where the systems built on it get better on their own over time, with full human control at every step. It's a capability that grows directly out of the product's declarative DNA, and one that is very hard to offer cleanly any other way.
The loop
Because the proposal is a reviewable diff, not opaque fine-tuning or self-modifying code, a human stays in control at every step.
Proposed first step (small, standalone PR)
None of the above is possible without feedback data, so I would start with just:
agent_manager(SQLite)This is valuable on its own (analytics on answer quality) even if the rest never happens.
If this direction sounds right, I'm happy to open the first PR. Also fine if you'd rather scope it differently, treating this issue as a discussion starter.