Category: Product

Most teams already own too many tools. Adding one more app rarely fixes the fragmentation, it just adds another place for information to live.

The idea behind Orbira is different. Instead of asking people to move, we want a thin layer that sits across the tools they already use, notices repeated work, and offers to take it over.

That means three design rules. First, start from the work, not the app. Second, keep a human approval wherever the stakes are real. Third, make everything explainable, so you always know what ran and why.

We will share more as the private beta grows.

The easiest way to make an automation tool look impressive is to let it do everything on its own. The easiest way to make it dangerous is the same thing. We have spent a lot of time on the question of when Orbira should stop and ask.

The asymmetry between reading and writing

Reading is usually safe. If a workflow looks at the wrong folder, nothing breaks. Writing is different. A message sent cannot be unsent. A file shared cannot be unseen. A deleted record may or may not be recoverable.

So our starting rule is simple. Steps that only read run on their own. Steps that send, share or delete wait for approval.

Three questions we ask about every step

Who will see it? Anything that leaves your workspace, or reaches a person who did not ask for it, needs more care than a private note to yourself.

Can it be undone? A task created in your tracker can be deleted. An email to a customer cannot.

How confident can we be? If the step relies on interpreting free text, such as deciding whether an email is a complaint, the chance of a mistake is higher than for a calendar lookup.

The more of these answers point toward “risky”, the more likely the step is to be gated by default.

Loosening the gates over time

Defaults should be conservative, but nobody wants to click approve forever. Orbira lets you relax a gate per workflow. A reasonable path is:

1. Approve every run for the first week.
2. Look at how often you changed anything.
3. If the answer is rarely, let low-stakes steps run alone and keep gates on the rest.

You can always tighten again. A single setting turns every gate back on.

What approval looks like

An approval request shows the proposed action, the inputs that led to it, and a button to approve, edit or reject. It is meant to be quick to read. If you have to dig for context, we have designed it badly.

What we are still working out

Approval fatigue is real. If every run asks for a yes, people stop reading and start clicking. We are experimenting with batching similar requests and with highlighting only what changed from last time. We will write about what works.