In search for parallel flow

For decades software engineers have relished deep, concentrated work, one problem at a time. Handcrafting each line, deeply engaged with map of the code they’re writing. Our interfaces, IDEs first and foremost, are built in support of this pattern, this pursuit of singular focused flow.

Increasingly autonomous software engineering agents require that we rethink this practice. As agents produce more code, quickly outpacing humans, software engineers will need to find flow in multi-threading rather than monocular focus.

We need new interfaces, new tools that embrace parallelism. Designed to lower the cost of context switching to a point where working on five things “at the same time” becomes a super power, not a burden.

Ona is such a system. In the following I want to outline design decisions and principles that we’ve found to be effective. As a product engineer and software developer, these design choices become anchor points for finding productive bliss in a world where multi-tasking is more inevitable than ever.

The sidebar in Ona isn't just navigation, but peripheral vision for parallel work. At a glance, users can see how far tasks have come along, which need attention, and which have completed. Designed to provide an overview at a glance, it's laid out in three columns:

1. First, the environment indicator: if it’s not green, no activity can happen in this environment. Either the agent is done, or has failed.
2. Second, the task description and progress indicator. If it shimmers, work happens; if it’s bold work has happened. The progress indicator, e.g. 2/5 help understand when attention is needed again. The second line is the current todo, providing feedback if the agent is working as expected.
3. Third, the change counter. An indicator for change complexity. The more files changed, the more complex the change itself. Helps judge if the agent is going of the rails, or works as expected.

Sidebar items never change their order to make spatial memory aid navigation. The order of sidebar items indicates time, older items are lower in the list.

Progressive engagement

The sidebar provides a global work overview; the conversation shows the agent’s current and past activities. Ona Agent’s conversations are optimized for density and intelligibility, for users to quickly get details about what the agent is doing. More than they are work history, they are a rolling display of detailed current activity.

It’s the editor that provides access to the work output of the agent: the source code. It becomes available with a single click, and is connected to the conversation (e.g. when clicking on file diffs in the conversation). The built-in VS Code diff view provides an overview of the changes the agent’s made.

Yet another level deeper are traditional IDEs connected to the this very development environment. It’s a bit like cars:

• the conversation is like highway driving: big trucks, high abstraction do the heavy lifting and provide mileage
• embedded VS code is like city driving, finer controls and more details compared to highways
• the editor is like a race car: very specialized, doesn’t work in the city let alone for long distances, but provides an intensely focused environment.

Situated actions and ineligibility

Suchman's observation that "plans are resources for situated action" rather than prescriptions for behavior deeply influences Ona's design. We don't try to predict your workflow; we provide resources that adapt to your situated needs, such as todos and slash commands.

Rather than depending on reliable recognition of intent, Ona focuses on the "collaborative production of intelligibility." The agent doesn't need to perfectly understand your plan, and instead works with you to produce meaningful outcomes. This is why we emphasize quick feedback loops and visible state over upfront specification.

TODOs help the agent maintain focus, and the user understand what the agent will do. They enable the user to act within the conversation, by e.g. choosing to observe the work, change the plan through their instructions, or switch to a different conversation with the intent to revisit this one once it’s done (as indicated in the sidebar).

Instead of aiming to produce a plan ahead of time, iterate on that, and then rigidly execute it, TODOs are a flexible feedback device that embed the user’s intentions with the actions of the agent.

Control minimizes risk over reward

Adoption and engagement come down to fear: the fear of doing “something stupid” (like deleting a production database), of not being seen as competent, as someone who drives quality or as someone who’s behind the curve. Whatever users value, engaging with new technologies is always a risk/reward calculation. What is the likelihood of something going wrong, and if it goes wrong, what’s the blast radius. And, what am I getting in return.

CAIR, the “confidence in AI results” describes this well as

Ona maximizes CAIR through control. Ona Guardrails ensure organization-wide controls. For individuals, three key ingredients limit the consequences and effort to correct:

• isolated environments mean that there are no wrong files an agent can edit, and few agentic actions with consequences harder to repair than the click of a button. Agents running locally require fine grained permissions to avoid dire consequences.
• no-cost immediate emergency stop button for the agent. Hitting ESC or pressing stop, cancels all agent activity in an instant. Resuming is as easy as prompting continue. No state is lost, no harm done. Being able to stop the agent immediately without consequences provides a deep sense of control.
• Git, and frequent commits, act as checkpoints. This is a well established and understood system, that developers know how to use.

Conclusion

Ona's design philosophy centers on a simple insight: when working with AI, the interface should amplify your ability to work in parallel without amplifying cognitive load. Every design decision—from the persistent sidebar to the minimal prompt box—serves this goal.

We're trying to get out of your way while giving you just enough structure to maintain control over parallel, AI-assisted workstreams. The best interface is one you don't think about—you just use it to get things done.