Ona Sessions: Moving Work From Chat to PRs

Redesigning Ona's core experience around the loop developers actually cared about: ask, review, edit, ship.

Outcomes

Overview

When I joined Ona, the company was mid-transition. The product had earned adoption as a cloud development environment, but the market was moving fast. Developers expected more from AI coding tools. They wanted agents that could investigate issues, make changes, review output, and move work toward a pull request.

Ona had the foundation for that. We had scalable environments, agent sessions, background work, code review, previews, and support for external agents like Claude Code. The problem was the product still carried too much of its Gitpod shape.

The experience was organized around environments. That made sense for a CDE product. It made less sense for a product moving toward agentic software delivery.

As I looked across customer feedback, usage data, company goals, and the broader market, the gap became clear. The environment was the how, not the why.

Customers cared about making progress. They wanted to ask for work, understand what happened, review changes, and ship with confidence. My job was to help reshape the product around that workflow without breaking trust with customers who still relied on the old mental model.

Reorganizing the product around Sessions instead of environments was not an obvious call. Environments were what customers knew us for, and three of our most agent-forward enterprise customers were tied directly into the embedded editor. Pushing that into the background carried real risk, and not everyone was sure we should. I made the argument anyway. As long as we kept anchoring the product to the environment, we would keep losing developers before they ever reached the agent.

This became one of the largest initiatives I led at Ona. I owned the direction, built the early prototypes to prove it was real, contributed directly to the frontend, carried enterprise customers through the change, and coordinated a staged rollout so we could ship it without breaking trust.

The mismatch

The first signal came from customers.

Enterprise teams liked the power of Ona. They liked how quickly they could get into a real development environment. But getting developers to try agent workflows was still harder than it should have been.

One engineering leader told us that getting Claude Code into Ona would make it easier to convince developers to use the product.

That stuck with me because Ona already supported Claude Code as an agent.

The issue was not raw capability. The product experience was getting in the way of people understanding the capability.

The original experience still reflected Ona's CDE roots. Conversation, environments, runtime controls, code review, and editor workflows all competed for attention in the same workspace.

Another customer described waiting on environments as friction before the work even started. They wanted to begin with a plan, understand what the agent was doing, and move toward review. They did not want to reason through runtime state just to feel productive.

At the same time, agent executions had become a key company metric. We wanted customers using agents to do real work, but the interface still gave the most weight to environments.

I also spent time looking across Claude Code, Cursor, Codex, Devin, Conductor, and other tools in the space. The strongest products were training users around a simple loop:

Ona had a chance to map to that expectation while bringing something different to the table: governed, scalable environments where agents could do deeper work against real codebases.

But to get there, the interface needed a new center of gravity.

The principles behind the shift

Before pushing into screens, I worked with our VP of Product on a set of product principles that could guide decisions across the team.

This project had a lot of tradeoffs. We were changing how customers understood the product, so the principles helped us make sharper calls. Four mattered most for this work.

Creating conviction

I started by mapping how work actually moved through Ona.

I looked at the happy paths, the debugging paths, and the moments where customers lost the thread. The goal was to understand the shape of the workflow before touching the interface.

• •Where do people start?
• •Where did they wait?
• •Where did they leave the product?
• •When did they come back and what helped them get back into the groove?

The most important question was about trust: where did the product need to give people enough context to let the agent keep going?

Mapping every path through Ona made the dependency obvious. Almost nothing could start until an environment was connected, and every branch, success or failure, ran back through the same gate. The environment was a precondition on the work, not a result of it.

From there, I used Figma to explore what Ona could be if Sessions led the workspace and environments moved into the background. It was the fastest way to test hierarchy and shape the direction before committing to code.

The vision I pitched to leadership. Conversation became the primary workspace, the environment dropped to a tab, and review sat right beside the dialogue. Most of this shipped, though where we landed shifted along the way, including a good deal of the visual identity.

Once the direction felt strong enough, I moved from static design into a working prototype.

I used Ona itself to build a functional prototype in an afternoon. It was rough. That was fine. The point was to make the direction real enough for people to use, challenge, and react to.

Leadership, engineers, and internal AI experts could pull the branch into their own environment and try it locally. That changed the conversation. We were no longer debating screenshots. We were talking about how the product behaved.

The prototype did not try to reach the full vision. It took the first real step toward it. I kept the embedded editor in place and reworked the structure around it. I added a way to view changed files inside the main workspace, placed on the right to tie into the output panel, which was an IA idea we later changed. I enabled a split view, simplified the right panel to drop environment detail and focus on output, and moved ports and services into a bottom panel. It was mostly cleanup and simplification, enough to show how the flow could be structured without pretending we could reach the full vision in one release.

That was the value. The vision gave us something to aim at, and the prototype made the first step concrete enough to react to. It reframed the work as a sequence of hills instead of one big leap. Some of what I explored shipped. Some waited. The conversation moved from whether the direction was right to how far we should go in the first release.

Designing the bridge

A clean future-state version of Ona would have made Sessions the obvious center of the product. A developer could hand off a ticket, let Ona work in the background, come back to review the output, request edits, and ship.

The problem was that customers were not starting from that future. They still understood Ona through environments. Some teams relied on the embedded code experience. Trust in agents was growing, but it was not complete enough to remove the parts of the product that made people feel in control.

So I made a deliberate call to pull code and environments into the background while keeping them in place.

Conversation became roughly 70% of the workspace, which made the agent and task progress the main focus. The remaining space was reserved for output: changed files, review, previews, and supporting tools. This gave us a clearer path toward the future product without making existing customers feel like the floor had disappeared under them.

What shipped

Sessions became the product model

Internally, the work started as Conversation v2. In product, it became Sessions.

That shift was important because “conversation” only described one part of the experience. Customers were not just chatting with an agent. They were opening a task, giving Ona context, letting work run in an environment, reviewing changes, and deciding what should happen next.

A “Session” would give our customers a better mental model.

A Session could hold the conversation, the environment, the agent’s work, changed files, review state, and future capabilities like terminals, previews, and external agent workflows. It let us keep the power of environments while moving them out of the center of the experience.

By centering the experience around Sessions, the workflow became much easier to explain to customers:

That became the bridge between where Ona had been and where the product needed to go. The environment was still there, but it became part of the Session instead of the first thing customers had to manage.

A Session opens to one workspace. Conversation sits at the center, changed files and review live on the right, and environment tools stay within reach. One clear place to start any task.

Code stayed visible because trust takes time

I did not want to hide code.

Customers still needed to inspect files, view diffs, request edits, and approve changes before anything moved forward. Review is where trust gets built.

The new experience kept code close to the conversation so users could understand the relationship between what they asked for and what actually changed.

Review stayed close to the conversation. Users could open a diff, see exactly what changed, and request edits without rebuilding context somewhere else.

Infrastructure moved into supporting patterns

Environments, terminals, services, MCP integrations, and future preview experiences all needed a place to live.

The design could not solve only the current release. It had to become a system the rest of the org could build into.

I met with team leads across Ona to map upcoming work, then shaped the workspace so each new capability had a defined place to land. The four principles became shared language. Other designers and PMs used them to make their own calls, so the direction held even on screens I never touched directly. Terminals moved to a bottom panel that expands when needed and collapses when not. Services, MCP integrations, and previews each got a home in the layout. Teams could ship into the workspace without dragging the product back into noise.

Supporting tools moved into a bottom panel. Terminals, ports, services, and tasks each got a defined home that expands when needed and stays out of the way when not.

What we cut, and what we kept

The first version had to ship quickly, but it also had to be good. That meant being clear about what belonged in the first hill and what needed to wait.

Embedded VS Code stayed. Reducing the role of the embedded editor was part of the longer-term vision, but it needed time and evidence to get there. Those same agent-forward enterprise customers were tied directly into the embedded editor, so pulling it back carried real risk. Internally, opinions on keeping the editor ran strong, and those opinions had to be weighed against actual usage. When I looked at real Core and Enterprise data, it did not show the editor mapping to real-world usage the way internal sentiment assumed. So for this release we kept the embedded experience, reduced its prominence, and tracked usage closely so the next call could follow the data.

The embedded editor stayed in place. Customers who relied on it kept full access while we reduced its prominence and watched real usage before the next call.

Preview moved to a later release. Integrated previews were part of the vision, and I believed strongly in their value. Seeing the result of an agent's work without opening another tab would make the product feel much more output-driven. The work required more backend and performance investment than we could fit into the first release. I continued leading the design direction for that effort, but we sequenced it behind the foundational workspace change.

Sidebar changes were scoped down. I explored larger sidebar changes that would better support Sessions, PR status, and future workflow states. Some of that work made it into later iterations, but the full version depended on APIs we did not have yet. Rather than force a shallow version, we separated it from the first release.

Mobile focused on parity. Mobile usage was low, but the new experience still needed to work. I updated the mobile experience enough to preserve core workflows and avoid breakage, while treating deeper mobile-first work as a separate future investment.

Shipping under real constraints

The original plan targeted a major release within a month.

The scope was ambitious, and the team was small. As priorities shifted across the company, engineering capacity changed. What started as a multi-engineer effort became a much tighter execution path, with one engineer carrying the core implementation while ramping into the product and codebase.

I adjusted the plan around that reality.

We delayed the release to protect quality, narrowed the first hill, and focused on the foundational changes that mattered most. I also moved closer to implementation, working directly in the frontend alongside engineering to keep momentum high and make sure the shipped experience matched the product direction.

That included the new layout structure, tab interactions, split-view patterns, drag-and-drop behavior, sidebar updates, mobile parity, changelog updates, and the Sessions rebrand.

Split view let users keep the conversation and the code side by side.

The same split could pair the conversation with a diff, so review never meant losing context.

The important call was not pushing the original scope through just to hit the date. This was a fundamental change to how customers understood Ona. Rushing that shift would have created more risk than speed.

Rollout and stabilization

A change this large needed a careful rollout.

I coordinated the release in stages over roughly a week and a half. We started with a small group of high-signal enterprise customers who were already leaning into agent workflows and likely to provide useful feedback. After five business days, we expanded to the rest of enterprise. Once feedback remained stable, we launched to Core and Free users.

During rollout, I worked with Customer Experience, Support, Engineering, and internal teams to monitor feedback and respond quickly.

One early concern was that some users could no longer find their environment as quickly as before. Even internally, there were questions about whether we had pushed too far.

I held the direction but adjusted the bridge.

For a short period, we auto-opened the environment tab to reduce discomfort. As users adjusted, behavior showed they were not relying on it as much as expected. We later removed the auto-open behavior and kept the environment available when users needed it.

Early discomfort can look like failure if you react too quickly. In this case, the direction was right, but the transition needed a little more support.

Outcomes

The redesign shifted behavior toward the workflows we wanted Ona to support.

Agent executions per day climbed from a 736 baseline, and active users from 3,709. In the first two weeks, 2,810 users across 888 organizations ran agent executions.

New users found their footing faster

Web session to signup climbed from a 6.5% baseline, and 7-day signup-to-agent activation from 11.5%.

Reflection

This project taught me a lot about trust, tools, and how quickly product work can move when the right people have the right systems around them.

Trust is the adoption problem. Customers did not need more proof that agents were powerful. They needed clearer ways to understand what the agent was doing, inspect the output, and stay in control. That shaped the product decisions. Code stayed visible because review builds confidence. Environments stayed accessible because customers still understood Ona through that mental model. The rollout happened in stages because changing how people work is not something you brute force into production and hope everyone claps.

Figma became my thinking space. I do not buy the "Figma is dead" argument. I still used Figma throughout the project. It was where I explored the system, moved pieces around, mapped flows, and worked through what the experience needed to become. What changed was where the work went after that. Instead of polishing screens forever, I could take the direction into Ona, build with agents, and feel how the product behaved. That gave me a much better read on what was working, what was awkward, and where the design needed sharper guardrails.

The bottleneck moved. A project like this used to take months of translation between strategy, design, prototype, and implementation. With agents, that distance got much shorter. The hard part was knowing what mattered, what to cut, when to hold the line, and how to help customers move into a new way of working without losing trust. That is where design still has to lead.

Where it landed: work happens inside the Session, review stays one click away, and the environment waits in the background until it is needed.

Ona blog

Designing for Collaboration: How we rethought Ona conversations