Make agents better with scored loops.
Self-improvement in Spark is not vague optimism. It means a repeated workflow gets a benchmark, a specialist path, a safe loop, and a visible record of whether the agent actually improved.
For public builders, Spark Domain Chip Labs is the starting place for creator standards, benchmark packs, specialization paths, autoloops, and publish packet drafts.
The plain-English model.
A normal skill can help once. A benchmarked Spark specialization can get better every time the same kind of work appears again.
From repeated work to a better agent.
The important part is the score. Spark should not promote a change because it sounds clever. It should promote it because it improves a benchmark, a rubric, a replay, or a real workflow outcome.
Researcher, OTOLO, and domain chips.
Spark Researcher is the lab runner. OTOLO/autoloops are bounded loops: one task, one score, a few rounds, then a review. Domain chips hold the specialist knowledge so Spark core does not become a pile of one-off tricks.
Spark Domain Chip Labs owns the public templates and standards for creating chips and paths outside the core runtime.
How the lab stays understandable.
- operate a startup
- plan better marketing
- run automations
- review code or tools
- evaluate: score the work
- suggest: propose the next safe change
- packets: save grounded lessons
- watchtower: show a readable report
- better reasoning
- better decisions
- better tool usage
- better project execution
This is why domain chips matter: the benchmark and the specialist path live together. The agent can learn startup judgment, marketing taste, automation reliability, or project execution without pretending one generic prompt solved every domain.
What benchmark improvement means.
A benchmark can be an automated test, a rubric, a replay, a human-reviewed scorecard, or a workflow outcome. The shape can change, but the rule stays the same: improvement must be visible.
Promotion ladder for a better agent behavior.
Before the loop
The agent can do the task, but misses evidence, chooses weak tools, or makes fuzzy decisions.
After Researcher runs the loop
The chip changes one path: better rubric, better prompt, better tool call, better memory packet, or better review checklist.
After review
If the score improves and the change is safe, the lesson can become part of the agent's repeatable path.
What this helps users do.
Operate with sharper judgment.
A startup chip can score positioning, sales follow-up, launch checklists, investor updates, or founder decisions against a rubric that improves over time.
Make content and campaigns less random.
A marketing chip can compare hooks, evidence, audience fit, distribution plans, and outcomes so future work gets closer to what actually performs.
Make workflows more reliable.
An automation chip can replay a workflow, score failures, improve tool usage, and preserve the repair lesson for the next run.
Execute with better tools.
A project chip can watch whether the agent picked the right files, commands, plugins, tests, and review steps before claiming the work is done.
Ask your local agent to design a path.
The easiest first step is not "make Spark smarter." It is "pick one workflow and define how better will be measured."
Use Spark Researcher's domain-chip authoring docs to design a new Spark domain chip for <domain>. Treat it as both: 1. a reusable tool my Spark agent can call 2. a bounded specialization loop Spark Researcher can run and score Ground it in the real Spark chip contract: - Spark Researcher owns loop execution, ledger, queue, memory index, vault generation, and review policy. - The chip owns evaluate, suggest, packets, and watchtower hooks. - Keep benchmark-grounded evidence separate from exploratory frontier ideas. - Add tests for evaluator, suggestions, packets, watchtower, and one runtime integration path. First inspect the installed Spark Researcher docs at: ~/.spark/modules/spark-researcher/source/docs/master_chip_v2/MASTER_CHIP_OPERATOR_PROMPT.md ~/.spark/modules/spark-researcher/source/docs/master_chip_v2/MASTER_CHIP_TESTING_PROMPT.md ~/.spark/modules/spark-researcher/source/docs/AUTOLOOP.md ~/.spark/modules/spark-researcher/source/docs/CHIP_ONE_LOOP_FLYWHEEL.md Then propose the smallest v0 chip and ask before writing files.
Safety boundary
The chip can suggest, score, and prepare memory packets. Risky file changes, public publishing, production writes, and secret handling should stay review-gated.