Giordano “Gyo” Piazza, GitKraken’s Director of Engineering, has spent the past month heads down on the next version of Kepler. When he got on a call to talk through it, he skipped the changelog and went straight to the part he actually wanted to talk about: how agents show their work.

“Personally, I think it’s a much more interesting way of following what agents are doing,” he said, “rather than reading through a waterfall of text, which is what we do when we are staring at an agent just blobbing out a lot of text. Which is very difficult, at least for me, to parse and focus on what’s going on there.”

That’s the problem the agent graph is built to solve.

A waterfall of text was never the endpoint

Anyone who’s run a coding agent for more than a session knows the waterfall. Text streams down the terminal, a tool call here, a file read there, a sub-agent spun up to handle one piece of the task, all of it scrolling past in a format built for logging, not for understanding.

Gyo’s read on it is simple: humans weren’t built to parse that. “Humans are visual creatures,” he said. “We process images tens of thousands of times faster than text.” The agent graph is Kepler’s answer, a graphical view of every agent, sub-agent, and tool call in a task, replacing the scroll with something closer to a map. It sits alongside the commit graph as the other half of how Kepler shows you what’s actually happening, one for your code’s history, one for your agents’ activity.

For a developer running several agents across several repos, that’s the difference between checking in on a task and reconstructing it from scratch every time you look.

Actions turn repeated prompts into a click

The agent graph solves for observability. The other piece of this release solves for repetition.

“Kepler comes with predefined actions now,” Gyo explained, “like plan, implement, review actions that you can execute on issues or PRs, and they can be customized. You can add more, and they support skills or simple prompts.”

If you’ve been running the same kind of prompt against every new issue, that’s exactly the pattern actions are built to remove. Pick an item from your Todo list, choose an action, and Kepler creates the task, attaches the repo, sets up the worktree, and starts the agent with the right context already in place. The built-in actions cover the common cases, plan, implement, review, but nothing about them is fixed. Teams can define their own, built on their own skills or a straightforward prompt, and reuse them across every issue that fits the pattern instead of retyping the same instructions.

Combined with the refined UI for issues and pull requests in this release, the shape of the workflow is: pick the work, pick the action, watch it run on the graph instead of the waterfall.

What this actually changes

None of this replaces the developer’s judgment. The agent graph doesn’t decide anything, it just makes the decision easier to make by showing the work instead of narrating it. Actions don’t skip review, they skip re-explaining the same task for the fifth time that week.

Gyo put it plainly: this release is the direct result of a month spent taking feedback from people already using Kepler and building the next evolution around what they actually asked for. The changelog, by his own account, is long. The agent graph and the action system are the two pieces worth understanding first, because they change how the tool feels to use day to day, not just what it can technically do.

Kepler is free to try during public preview at gitkraken.com/kepler.