Cross-team work with responsibility attached

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. This scenario is the cross-team case: a list arrives from one department, another department’s agent acts on it, and the question is who is accountable for each row.

How does work move between teams and agents without losing the owner?

GembaOS keeps one persistent work item for the whole workflow and routes every transition through the policy, so that each specialist agent receives only the context its role may see and each decision lands with the human owner named for that step. A list of many rows becomes one aggregated approval request; the owner signs once; every row executes under its own clearance token.

	Before	With GembaOS
The hand-over	An email with a spreadsheet, forwarded twice	A work item that carries the list, its source and every transition
Context	Every agent sees everything	Separation of duties: each role sees its fields, nothing more
The decision	“Please process” from whoever forwarded it	One signature by the designated owner, on the facts as they stand before the change
A typo in the list	The whole batch fails, or the wrong account is touched	That row fails alone and is reported; the other rows go through

What happens, step by step?

Step	Who	What is recorded
1. Intake	HR hands over the month-end leavers; the batch page parses the rows	The list as it came, and how it was read
2. Pre-read	The host reads each account as it stands	The facts per row; an unreadable row shows as such
3. Aggregate	One approval request with every row	The request the owner will see
4. Sign	The IT administrator, once, with a passkey	The signature chain
5. Clearances	One per row, each bound to its own arguments	Four clearances for four accounts
6. Execute	Row by row; a failure stops only its own row	Each execution and its outcome

Where is the control point?

The control point is the single signature on the aggregated request, taken on the pre-read facts. Nothing in the list can widen what the signature covers: a row that was not on the request has no clearance, and a row whose account changed since the pre-read is returned rather than executed. The Gap Register collects what the process lacked, such as a missing hand-over rule, for the owner to fill in later.

What does it look like in the console?

GembaOS batch page with the leavers list parsed into four rows

GembaOS approval desk showing one aggregated request with four account rows

GembaOS batch page after execution showing three stopped accounts and one failed row

What do we need to start?

The hand-over as it happens today: the list format, who sends it, who acts on it.
The identity or account system the rows touch, through the REST, SQL or worker adapter.
The owner who signs for that class of change, from your authority table.
Optionally, a ticket system to mirror each batch into, so the record appears where the team already looks.