Where we stand

We kept seeing the same gap: companies did not lack AI tools, they lacked the capacity to turn them into dependable work. Rhyme has spent years building products, integrations and operational workflows. Orbital is how we make that experience repeatable: a crew member with a defined job, inside a real workflow, answerable for an outcome you can check.

A tool leaves the hard part with a person: deciding what matters, supplying context, following up, connecting systems and knowing when to escalate. A crew member is built around an outcome rather than a prompt. It has a role, an operating context, routines, and a working relationship with the people who own the work.

Rhyme Sthlm, based in Stockholm. Orbital is a Rhyme product, and the people who build it are the people you meet in the brief. Client work carries on; Orbital is where what we learn from it is packaged as reusable roles, governance patterns and workflows.

We expect the best organisations to have crew members working alongside their teams, holding defined operational responsibility in places like research, coordination, customer operations, finance and delivery. Not in place of accountability: people set the direction, exercise judgement and own the consequences, while the work gets faster, more consistent and easier to see.

A role you define, held by software. It has a scope written down before it starts, a named person it answers to, a permissions boundary it cannot reach past, and a log of everything it does. Capability comes after all of that.

A chatbot or assistant is reactive: you ask, it answers. An automation runs a fixed path. A crew member has a mandate, a defined workflow, a standard its work is checked against and clear boundaries. It follows work across the systems it has been given, prepares, monitors, coordinates and improves it over time, and comes back with it done, or with the one question only a person can answer. It does not get to invent its own authority.

The ones you write. Stellan, Sally, Buzz, Saga and Lando are worked examples of what a role looks like once someone has described it the way they would describe a colleague. Yours are shaped around processes only you run.

It takes a scope, not a job. The work it picks up is the part that was being lost between systems; the decisions, the judgement and the relationships stay with your team, and the log says which is which.

Because useful AI ends up touching consequential work. If nobody can say what a crew member is responsible for, who it answers to, what it may do and how its work is checked, you have a demo, not an operating model. Responsibility is what turns capability into something a company can rely on.

Trust is not a setting. A crew member starts read-only, moves to drafts a named reviewer checks, and only then to scoped work. Each step up rests on evidence in the log, and each can be reversed: if exceptions rise, responsibility moves back down.

A narrow, valuable first job. A named owner. A clear measure of success. Least-privilege access and a log you can read. Approval paths for consequential actions. And a way to stop it and roll back safely. You should be able to see what it did, and where a person’s judgement stayed essential.

With a paid Mission Brief. We map the process with the people who run it, agree the scope a crew member would hold, and say plainly what we would not put inside it.

Rarely the model. More often it is unclear ownership, a process nobody has written down, data scattered across systems, or an exception everyone handles by hand and never mentions. Deployment is organisational design as much as technology, which is why the best first win is small: one workflow, one owner, one agreed measure of better.

First value is a matter of days. At day 30 you decide whether the pilot has earned an ongoing crew member. Nothing else on the arc carries a clock — the six stages are earned, not scheduled.

We do not publish prices. The Mission Brief is a paid engagement, priced against the scope it agrees, and what follows is priced against what you decide at day 30.

The ones you already run. We do not publish a list, because which systems a crew member touches is part of its scope and is settled with you in the Mission Brief rather than assumed from a logo wall.

The named person the work belongs to. Work that needs a decision waits for them, and nothing advances on the crew member’s own authority.

It is caught where the phase expects it. Read-only, it cannot change anything; on drafts, a named reviewer sees the work before it goes anywhere; on scoped work, the rollback has already been rehearsed. The log shows what it did and under which scope, so you are correcting a record rather than guessing.

Yes, in one place, at any time. Autonomy is reversible at every stage — that is what makes it possible to grant in the first place.

Inside the commitments you already have: single tenant, Data control, your identity provider, your retention policy. There is no parallel stack to approve, and security review runs alongside onboarding rather than after it.