Large tasks rarely produce one logical change. They usually produce several changes that belong in separate commits, but without a dedicated workflow everything accumulates in the same working tree. Unrelated changes get mixed together, logical slices become harder to preserve, staging becomes risky, and reviews become larger than necessary.
A better workflow would preserve each logical slice as soon as it is complete. That slice should include the affected files, a proposed commit message, the relevant test commands, and the exact patch. Once preserved, the working tree should be restored so the agent can continue with the next slice independently.
But preserving slices is only half the problem. The agent should be able to organize the work without controlling Git history. The developer should still review every staged diff and create every commit manually.
That is what Agent-Up commits provides. Agent-Up commits is a local commit proposal queue for agent-assisted development. Agents enqueue proposals instead of creating commits, and each proposal stores its patch and message before restoring the working tree.
Later, the developer runs agent-up commits next. Agent-Up applies and stages exactly one proposal. With the JetBrains plugin, a single button takes the first proposal in the queue and opens it directly in the IDE's commit window. The developer reviews it in the IDE, runs the relevant tests, and commits it manually. Then the next proposal can be reviewed.
Agent-Up does not replace Git. It adds a safety layer between agent-generated changes and human-controlled commits, so agents can preserve logical slices while they work, developers can review one staged proposal at a time, and Git history remains under human control.
Get the JetBrains IDE plugin
https://plugins.jetbrains.com/plugin/33179-agent-up-commit-queue
Top comments (2)
The proposal queue is a useful separation of capability from authority: the agent can preserve a patch and explain its intended slice without owning Git history. I would apply the same rule to the queue item itself: store a base commit, affected-file list, test commands, and a content hash, then refuse to stage if the working tree or base has drifted. That turns “review this patch” into a reproducible checkpoint rather than a moving target. Do you also record which agent/tool produced each proposal so a later review can compare failure and revert rates by harness?
Storing all these details alongside the queue entry would certainly make the patch better reproducible.
But so far I was just thinking of splitting up the changes from a larger agent run into more manageable reviewable pieces. They should only last till the next large agent run.
I have a checked invariant that the same file is not allowed to appear in multiple elements of the queue. With that I want to enforce that changes don’t overlap and only target individual slices.
And yes, I’m scoping the patches by working directory. Since I only run one agent per working directory that’s effectively scoped per agent.