Orbit is an agentic AI workspace for tasks that normally require moving between applications. A request can involve finding information, reading email, working with business data, writing a response and preparing an action. Orbit coordinates the capabilities needed to complete that work, while the conversation gives the person a consistent place to understand progress and decide what happens next.
03 / THE PROBLEM
The more an AI can do, the more important control becomes.
A conventional assistant mostly produces an answer. An agent can retrieve information, combine context from different systems and prepare actions that affect the world outside the conversation. The interaction needs enough visibility for someone to understand what is happening, without making them supervise every internal step or manage the tools themselves.
04 / Defining the product
Asking and acting need different boundaries.
The distinction that shaped Orbit was consequence. Searching can happen quietly, and a draft can be reviewed before it goes anywhere. Sending an email or changing business data requires a different level of control. I used that distinction to decide where the system could move independently and where the person needed to make a decision.
01Show the plan when it matters
Complex requests need an understandable plan. Routine internal steps do not need to compete with the work the person is trying to complete.
02Context should travel
Information found through one capability should be available to the next, without asking the person to copy it between tools or repeat the request.
03Confirm consequences
Orbit can prepare an action, but preparation and execution are different states. Actions with external consequences need a clear opportunity for review and confirmation.
05 / Designing the system
A conversation with a system behind it.
A request becomes a plan, relevant tools are discovered, and the context they return informs the proposed action. Confirmation sits between preparation and execution when the consequence requires it. The result returns to the same conversation, so the person can continue the task without navigating a separate interface for each capability.
01Request + plan
02Tools + context
03Prepared action
04Confirmation
05Result
Request → plan → tools → context → action → confirmation → result
06 / Key product challenges
The decisions that shaped the product.
Useful progress without an execution log.
01The thinking
An agent needs to make its work understandable, but exposing every tool call makes the user manage the system instead of the task. An unexplained final answer creates the opposite problem: there is no basis for reviewing an action.
02The decision
Focus progress on useful findings, prepared actions and points requiring a decision. Keep drafts separate from actions that have been executed.
03The result
The conversation carries a readable account of the work, with explicit boundaries between preparation, approval and completion.
07 / The solution
Make the work visible at the moments that matter.
JOURNEY 01
From a useful finding to a reviewable draft.
A request involving mail, search and writing needs more than tool selection. The useful information has to carry into a draft that the person can inspect. This example makes the interaction concrete: find context, prepare a response, then let the person decide whether it should be sent.
01Find the context
02Prepare a response
03Review the draft
04Confirm sending
Mail and writing task / review before external action
JOURNEY 02
Autonomy, with boundaries.
Tool discovery, MCP connections and context passing sit behind the conversation. The interface needs to distinguish what the agent is preparing, what requires a decision and what has actually completed. Recovery belongs to that same task, rather than a separate technical error screen.
01Prepared, awaiting confirmation, completed
A draft is available to review; a consequential action waits for confirmation; a completed action returns a result. These states communicate different levels of commitment.
02Unavailable capability
An unavailable connection leaves a part of the task unfinished. Explain the missing capability and the useful work already completed, so the person can choose how to continue.
03Partial failure
If one step fails after another succeeds, keep those outcomes distinct. Recovery should address the unfinished work without implying that the whole task completed or inviting the user to repeat a successful action.
08 / Outcome & impact
An interaction model for work across tools.
My contribution was connecting the system’s capabilities to a readable interaction: useful progress, reviewable drafts, consequence based confirmation and recovery in the same task context. The mail and writing example shows how context can move between tools while the person retains control over sending. Prepared work and completed work remain separate states.
01A shared interaction model
Mail, search, writing and business data follow the same pattern of intent, preparation, review and result, even when their capabilities differ.
02What I learned
Greater AI capability makes boundaries more important. Deciding where an agent should pause, explain or ask for confirmation is part of the product experience. Those moments give people a reason to trust the work without asking them to understand the system’s internals.
09 / Success criteria
Success criteria: measure completed work and informed control.
Evaluate task success alongside understanding of action states. Faster execution is useful only when people know what happened and retain control over consequences.
Task success
≥90%
Requests reaching the intended outcome across the required tools, with prepared drafts distinguished from executed actions.
Action comprehension
≥95%
People correctly identifying what is prepared, awaiting confirmation or completed.
Recovery effort
≤2 min
Time to recover unfinished work after a tool or connection failure without repeating an action that already succeeded.