Most teams adopting AI agents are making a bet on which one wins. Claude or Codex, Copilot or something newer next quarter. That bet is the wrong one to make. The agent you use will keep changing. The workflow around it is what actually needs to hold up.

That’s the philosophy Kepler was built on, and it’s different from the problem we’ve talked about before: not just too many terminal windows, but a deeper question of what happens when the tools inside those windows are locked to whoever built them.

The problem with picking a favorite agent

Every agent comes with its own walled interface: its own desktop app, its own IDE extension, its own CLI. Standardize on one, and you’ve also standardized on its limitations. Let developers pick their own, and now the team is coordinating across five different systems that don’t talk to each other.

“In the spirit of all things GitKraken, where we try to be agnostic to the systems developers work with every day, we wanted to build something that would let you work with any of these agents,” said Justin Roberts, Senior Director of Product at GitKraken. “It shouldn’t matter if you use Claude, Codex, or Copilot. You should be able to connect to whichever one you’re using and start getting work done.”

That’s agentic agnosticism: Kepler doesn’t ask a developer to commit to one agent. It connects to whatever they’re already running, and pairs that with the integrations already built into a GitKraken account, like issue trackers and hosting services, so the context a developer needs and the agent doing the work finally live in the same place.

A decade of Git intelligence, aimed at a new problem

Connecting to any agent solves half the problem. The other half is what happens once an agent starts touching real code: creating branches, opening pull requests, running into conflicts.

GitKraken has spent more than ten years building Git-focused tools, and Kepler puts that experience directly to work. Spinning up a work tree so an agent has a safe sandbox to operate in. Rebasing changes onto main automatically to keep work current. Surfacing a conflict the moment it happens, with a tool to resolve it and a chance to review the agent’s output before it moves forward.

“We want to take the pain of working with Git away in an agentic environment, the same way we’ve done in GitKraken Desktop and GitLens,” Roberts said. “Developers shouldn’t need to think about Git mechanics anymore. They should think about the goal they’re trying to achieve, and how agents can help get there.”

That’s a shift from a repo-centric view of development to a task-specific one, where the work matters more than which repository it happens to live in, even when a task spans more than one.

From one thread to several

Development has always been mostly single-threaded: take an issue, branch, write the code, open a PR, get it reviewed, merge, repeat. Agents break that model, because they can run pieces of that process on their own, in parallel, while a developer does something else.

Before Kepler, taking advantage of that meant multiple terminal windows or multiple IDE instances open at once, each one another thing to keep straight. Kepler is built to lower that cost, whether someone is just starting to run one or two agents at a time, or already has complex workflows built on their own skills and plugins.

What’s next

Kepler has been in feedback sessions with real GitKraken users since it opened, and the signal so far has been positive: teams already running agentic workflows are validating the direction and shaping what comes next, including a system for team-configurable actions that will let teams customize how planning, implementation, and PR review happen inside their own process.

Try Kepler in Public Preview today.