Agent Experience Merge Requests
When an agent repeats a mistake, turn a human correction into team knowledge that can be replayed as a test, reviewed, and rolled back.
When an engineer sees an agent misunderstand the same configuration, testing convention, or permission boundary again, the correction does not have to disappear into the next chat. They select the correction, attach the relevant code, tool calls, and a correct example, then submit an “experience merge request.” The system first turns it into a readable rule: which repository it applies to, what to do under which conditions, and where it must not be applied.
Submitting an experience does not broadcast it to every agent immediately. The product draws a replay set from the team’s completed, de-identified tasks and runs the old and proposed rules separately. The page places side by side the errors fixed by the new rule, the regressions it introduces, and cases that cannot be judged. Reviewers can inspect the original context that triggered each outcome rather than relying on a pass rate alone.
Approved experience enters specified repositories and task types with a version number. If an experience causes regressions in later tasks, the owner can identify affected conversations, revert to the previous version in one click, and leave a new improvement request. Over time, the team builds an agent playbook that can be reviewed, tested, and rolled back like code.
The first version accepts only explicitly submitted human corrections and covers common code-editing and tool-call tasks. It does not quietly extract every private conversation or let a model turn a single accidental success into a global rule.
Why now
As observed on August 9, Hexis ranked first in Product Hunt’s new-product feed and promotes Git-based management for agent skills, tools, and context. S1 Teams can now see that shared rules already have a home; what is missing is a way to validate corrections through replay before approving and distributing them.
Target user
Engineering teams using coding agents, especially those responsible for code review, development standards, or internal platforms. When the same mistake resurfaces in merge requests, verbal reminders become inefficient. They already have the failed conversation, correct code, and test results; capturing those materials immediately is both the lowest-effort moment and the clearest time to define the rule’s boundaries.
Minimal entry point
Place a “Submit correction” action beside coding-agent conversation logs. The user selects a conversation excerpt and attaches relevant files, tool calls, and the correct outcome. The system drafts a structured rule with fields for applicable repository, trigger conditions, expected action, and exceptions. Rules and samples are stored in a Git branch, and a merge request is created through the GitHub REST API. S3 The replay runner initially supports repeatable command-line coding tasks, loading the old and new rules separately in an isolated environment. Its results page shows fixes, regressions, and indeterminate cases individually rather than reducing them to one score. Early evaluation relies primarily on deterministic tests and human review; automatic rollout is deferred.
Punching above its weight
Start with engineering teams that maintain CLAUDE.md, AGENTS.md, and repository rules. Release an open-source command-line tool that converts existing rule files into sample-backed experience requests. Provide common templates for test commands, package-manager selection, and permission limits. Publish technical case studies with real before-and-after replay differences in coding-agent communities and forums for internal engineering tools.
Competitors & gaps
- HexisGoogle
- Hexis already puts skills, tools, and context on top of Git. It offers versioning, a friendly change-proposal interface, and access controls. Team members can also use the content across agents through MCP. S1 That addresses rule storage, sharing, and approval gates. Its public materials still focus on content governance and distribution. They do not show a workflow that turns a human correction from a conversation into a candidate rule, nor do they explain how historical tasks are used to compare old and new rules. Hexis could therefore serve as the downstream rule repository rather than requiring a duplicate governance layer.
- Claude Code Memory and CLAUDE.mdGoogle
- Claude Code already supports CLAUDE.md, project rules, and auto memory. Auto memory accumulates notes from corrections and preferences, while teams can share project-level instructions through version control. S2 These features are close to the immediate need to stop repeating the same mistake. The limitation is that auto memory is more oriented toward an individual working tree and maintained by the model itself. CLAUDE.md can be reviewed through ordinary Git workflows, but has no dedicated correction-submission flow. The official documentation also does not provide task replay comparisons between old and new rules. The opportunity is to add evidence, review, and regression tracing—not another memory file.
- LangSmithGoogle
- LangSmith can already turn production traces into datasets. Datasets can be versioned and used to compare experiment results. Its interface shows inputs, outputs, feedback, and complete traces, and it can set an experiment as a baseline to identify regressions after a change. S4 This can support part of the replay and evaluation workflow. The gap is that it is built for general agent evaluation, not change governance for team knowledge. Engineers must still turn chat corrections into rules and samples themselves. After an evaluation passes, they must separately build the publishing, scope, and rollback paths for rules. A new product could use it as an evaluation backend while centering the experience on experience merge requests.
How it makes money
Charge a subscription per team workspace, including member seats, a rules repository, and a base replay allowance. Bill additional replay jobs by volume. Offer self-hosting, single sign-on, audit exports, and long-term retention in an enterprise plan.
The case against
Replay results are easily affected by changes in model versions, dependency states, and external tools. A rule may only happen to make one task pass. To distinguish a rule’s effect from random variation, teams need fixed environments and complete traces. Historical tasks may also contain secrets, customer code, and employee conversations, so de-identification adds adoption friction. Many corrections cannot be written as deterministic tests and require human judgment. If reviewers must inspect long conversations case by case, approval becomes another workload. A flawed rule distributed widely can make many agents fail in a more consistent way. The product must first prove that replay evidence reduces review time; otherwise, ordinary Git files are simpler.