An agent works on a task for three days. At six in the evening, who is handling it?

GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC.

Agents are starting to take on work that runs for hours or days. That raises a question most teams have not had to answer for software before: while the agent is working, who is in charge of it? The person who asked? Anyone who opens the screen? And at six in the evening, when that person goes home, who has it then?

The easy answer, and why it fails an audit

A common answer right now is to share the agent the way a team shares a document: anyone can open the session, see what it is doing and type into it. That is good for watching. It is bad for everything after: if five people typed into it and the agent then refunded a customer, who told it to? “The team” is not an answer an auditor accepts, and neither is “whoever was logged in”.

GembaOS splits the two. Watching is open. Acting has one name.

Watching: open to anyone allowed to see the run

Every run has a live panel on its page. It shows who is handling the run, who has it open right now, and where the agent is. The first line says that this is a live view and that the record is the timeline below it. Who is watching is not written to the record, because watching is not an act.

Steering: only the handler

A run has one handler at a time. By default it is the person the agent is working for, so nobody has to configure anything. Only the handler can steer the agent, and a steer is one of three kinds:

• Context: something the agent did not know (“Finance rounds refunds half up”).
• Narrow: a smaller scope than the one it was given.
• Redirect: a different target, within what the playbook allows.

The agent reads the steer at its next step. It does not interrupt the step in progress; to stop now, the handler holds the run, steers, and releases it, and each of those is on the record in their name. A steer changes what the agent tries, never what it may do: it cannot add a tool, raise a limit or skip an approval, because every one of those checks happens after the agent has read its messages.

Handing over: two people, on the record

At the end of the day the handler offers the run to a colleague, with a reason. The run appears on the colleague’s desk under Assignments offered to you. Nothing moves until the colleague accepts, and an offer nobody accepts lapses after a day. There is no “they logged off, so it is yours”: a run nobody accepted is still the first person’s, and the record says so.

The pictures below are from one run of the demo named at the end of this note. The model in the demo is a stub that follows a script; the handler role, the steer, the handover and the signatures are the product’s own, exactly as they run with a real model.

Ken Adams, an engineer, asked the agent to fix a failing test. While it was working he added one line of context. At six the fix was waiting for the code owner, so he offered the run to Mia Young. This is her desk:

She opened it and accepted. The panel now names her as the handler (reassigned), shows both of them watching, and gives the steer box to her alone:

Anyone watching can also ask the assistant about the run. It answers with the asker’s own permissions, and only the asker sees the answer. The handler may use an answer as her own instruction; a watcher cannot, so an answer never steers the agent without a handler’s name on it. The run’s timeline records that she asked; the answer itself stays with her. (The demo’s model is the stub, so the answer here says only how much of the run it was shown.)

The signature did not move

The fix touches a code-owner path, so the route says the code owner signs. The handover changed who handles the run. It did not change who signs: the one remaining decision on the form is still the code owner’s, Susan Wright.

This is deliberate. Who signs comes from the route and the org chart the company configured, and the part of GembaOS that decides it does not read who is handling the run or who is watching it; a test fails if it ever does. The reverse is also enforced: someone who became the handler by a handover or a takeover cannot sign that same request on an ordinary band. They shaped the run, so the signature must be someone else’s, the same rule that stops a requester approving their own request.

The run’s timeline, after the code owner signed, has every one of these moves on it with a name: Ken’s steer and the step at which each part of the agent read it, the offer from Ken to Mia, the change of handler, Susan Wright’s signature and the merge.

The steer was read three times because three parts of the run each start their own conversation with the model: the specialist investigating, the specialist proposing the fix, and the lead reviewing it. Each of them is given the handler’s words.

What this does not do

• It does not let presence become authority. Being in the room gives no signature and no steer.
• It does not let two people steer at once and pick a winner. If two steers contradict each other, a playbook can let the agent say so; the question goes back to the handler, and the agent does not decide.
• It does not let the agent’s scope grow. A redirect the playbook does not allow is a new work item with its own approval.
• It is not in the public demo. A visitor there has no name, and a handler with no name is exactly what this feature exists to prevent. The pictures come from a local demo, where each person signs in as themselves: run gemba demo, open the employee page as two different people, and ask for the bug fix.

---

For architects

• On the record: a steer, an offer, an acceptance, a takeover, a hold and a cancel are each an event on the run’s hash-chained record, with the person’s name and, where the act needs one, the reason.
• Steer text is untrusted too: it goes through the same injection checks as any incoming message.
• Named logins only: a login with no named person behind it, such as a shared operator password, can watch a run but cannot be its handler, steer it or hand it over.