Who owns an agent skill when someone leaves
By Randy Olson, Co-Founder & CTO, Goodeye
Goodeye gives every skill exactly one owner, a single user account, and no administrator can reclaim it. Ownership moves only by a transfer the current owner starts and the new owner accepts, so offboarding has to happen while the departing person can still run a command. Deleting an account that still owns a live skill is blocked, which is a backstop rather than a plan.
Somebody on your team spent months building the runbooks your agents follow. They wrote the skill that drafts your release notes, the one that reviews migrations, the one that turns an incident transcript into a postmortem. Now they are leaving.
The code they wrote is in the repository and the documents are in the shared drive. The skills are on their account, which is a different kind of thing.
Most teams find this out in the wrong order. The skills keep working after the person goes, because access already granted keeps resolving, so nothing breaks on their last day. The gap surfaces weeks later, when somebody needs to publish a fix and the only account that can approve it belongs to a person who no longer works there.
A skill belongs to one account, not to the team
Every skill has exactly one owner, and that owner is a user account rather than a company, a team, or a workspace. Sharing does not change it. You can grant a skill to five people and a whole team at admin role, and every one of those grants describes what somebody may do with a skill that still belongs to the person who published it.
Ownership moves by transfer, not by administrator
Ownership in goodeye is per user account, and it leaves that account only by a transfer the owner starts. There is no organization-level override, in either direction: nobody can reassign what sits on a departed colleague's account, and equally nobody can reassign what sits on yours.
A teammate holding an admin grant can manage access while a handover happens, which is useful, but that is the limit of it. An admin grant does not let anyone assign the skill to themselves.
There is one backstop worth knowing, because it changes how urgent this is. An account cannot be deleted while it still owns a live skill: goodeye blocks the deletion and tells you to transfer first. So an ordinary account closure will not quietly destroy the work. The residual risk is softer and more common, which is an account that is deprovisioned, locked, or simply unattended, or a skill that was archived before the account closed. In all of those the skill is still owned by an account nobody can act from.
So the practical answer to "who owns the skill when they leave" is: they still do, unless you did something about it first. The rest of this guide is about doing it first.
List what they own while the account still works
Start from their account, not yours. Only they can see the full set:
goodeye skills list --filter mine
That is the working list for the rest of the offboarding. Expect it to be longer than anyone predicted, and expect two or three entries on it to matter more than the person realizes, because the skills a team leans on hardest are usually the ones nobody has thought about since the week they were written.
Transfer the ones the team depends on
goodeye skills transfer-ownership release-notes @newowner
This returns an invitation. It does not move anything yet. Ownership changes when the recipient accepts:
goodeye invitations list --filter received
goodeye invitations accept <invitation_id>
Three consequences follow from that invitation step, and all three bite people who run the transfer at the last moment.
It expires. A pending invitation lives 14 days. After that it lapses, and reissuing it takes the original owner, which is precisely the account you are racing. Start early, and verify acceptance rather than assuming it.
It carries dependencies. When the new owner accepts, each verifier and image generator the skill references is copied into their account, so the checks keep running under the new ownership. A dependency they already own is kept rather than duplicated, and a system: reference is left pointing at the live tier. If the skill references a verifier that has since been revoked or deleted, acceptance fails and the invitation stays open until the reference is fixed, which is another reason to run this while somebody can still fix it.
It does not cut the old owner off. On acceptance the previous owner is automatically given an admin grant on the skill, which lets them keep managing its grants. That is sensible for a planned handover and wrong for a departure, so follow the transfer with a revoke from the new owner's account:
goodeye skills revoke-grant release-notes former-colleague@example.com
Grant to the team, not to the person
Transfers handle the skills that already exist. The way to stop the next departure costing you an afternoon is to make team membership, rather than a list of individuals, the thing that carries access:
goodeye skills grant release-notes @platform-team edit
Every current member of that team inherits the role, and so does every future member. Somebody joining next quarter gets access by being added to the team, and somebody leaving loses it by being removed, with no per-skill bookkeeping in between.
A grant carries a version floor, which by default is the version current when you shared it. If the team should be able to read the whole history rather than everything from today forward, say so when you grant:
goodeye skills grant release-notes @platform-team edit --include-history
Teams have a single owner too, so the same question applies one level up. goodeye teams transfer-ownership platform-team @newowner moves it, again through an invitation, and the previous owner becomes an ordinary member once it is accepted.
Know what removing someone actually does
goodeye teams remove-member platform-team @alice
This ends team-derived access immediately, because team grants are resolved against current membership every time access is checked rather than copied out at grant time. It is also the whole of what it does, and the rest is easy to assume and wrong.
Direct grants survive. Anything granted to Alice personally is still granted to her after she leaves every team you have. Those come off one at a time:
goodeye skills revoke-grant release-notes alice@example.com
Skills she owns stay hers. Removing somebody from a team does not touch ownership, which is the whole reason the transfer step exists.
Removal normally emails the person, so treat it as visible rather than silent. Delivery is skipped if they have opted out of notifications, so do not rely on that email as your formal notice.
Check access before and after
goodeye skills grants release-notes --table
goodeye skills grants release-notes --json
The table gives grantee, type, role, whether access came via a team, and the version floor. The JSON adds granted_by and granted_at. You need to be the owner, or hold an admin grant, to read either.
Two limits matter if you are treating this as an audit. The listing has one row per grant rather than one per person: a team grant shows as a single row, and the members who reach the skill through it are never enumerated, so this is not a roster of everyone who can read the skill. And it reports current access only, so a grant revoked last month leaves nothing you can query. If your policy needs a durable record of who could read what and when, keep that record wherever you keep the rest of your access reviews.
If they have already gone
Say the transfer never happened and the account is now unreachable. You cannot take ownership, but the work itself is very likely not lost, because every machine that synced the skill holds a copy of it on disk.
goodeye skills sync status
Run that on a machine belonging to somebody who had access. Each mirrored skill was written to <target>/<slug>/SKILL.md, so the body is sitting there in the filesystem. Publish it from an account you control:
goodeye skills publish ./SKILL.md
Be clear about what this is. It creates a new skill that you own, carrying the body. It does not carry the version history, the original slug, or the grants, and any verifiers the old skill referenced have to be bound again on the new one. That is recovery rather than a transfer, and the difference between the two is the whole argument for doing the transfer while the account is open.
Where to start
Do not wait for a resignation. Run goodeye skills grants on the two or three skills your team would most hate to lose, and look at who owns them. If every one of them is owned by the same person, you already know what your next offboarding looks like.
Then move the access those skills depend on onto a team grant, so the next change is a membership edit rather than a scramble. If the handover also involves a skill whose behavior has drifted, roll back a bad agent skill update covers getting a known-good version back in front of the team while you work out what changed.
Frequently asked questions
What happens to an AI agent skill when its owner leaves the company?
Nothing automatic happens, which is the problem. A skill belongs to one user account and stays there after the person stops working for you. Access other people were granted keeps working, so the loss is invisible at first: the team goes on running the skill and finds the gap only when somebody needs to publish a change and the account that can approve it is unreachable. Goodeye does guard one case: an account cannot be deleted while it still owns a live skill, so the work is not destroyed by an ordinary account closure. What actually bites is softer: an account that is deprovisioned, locked, or simply unattended, or a skill archived before the account closed.
Can an administrator take over a skill owned by a departed employee?
Not by administrative override. Ownership sits with a user account and moves by transfer, goodeye skills transfer-ownership run from the owning account, rather than by seizure. That is deliberate and it cuts both ways: nobody can quietly take a skill off your account either. A teammate holding an admin grant can manage who else has access, which is what you want during a handover, but an admin grant does not let anyone assign the skill to themselves. Two habits make this a non-event: grant to a team rather than to individuals, so access never depends on one account, and transfer what the team depends on as an offboarding step rather than an emergency.
How do I transfer ownership of an agent skill to someone else?
Run goodeye skills transfer-ownership my-skill @newowner from the account that owns it. That returns an invitation rather than moving anything, and ownership changes only when the recipient runs goodeye invitations accept <invitation_id>. A pending invitation lives 14 days, and after it expires only the original owner can reissue it, which is the account you are racing. On acceptance, each verifier and image generator the skill references is copied into the new owner's account unless they already own it, and system: references keep pointing at the live tier. One thing the transfer does not do is cut the old owner off: they are automatically given an admin grant, so a real offboarding follows the transfer with a goodeye skills revoke-grant.
Does removing someone from a team revoke their access to its skills?
It revokes team-derived access only, and that part is immediate: team grants are resolved against current membership every time access is checked, so goodeye teams remove-member platform-team @alice ends everything Alice reached through that team. Any grant made to her directly survives untouched, and every skill she personally owns stays hers. A complete offboarding is therefore three passes: remove her from teams, run goodeye skills revoke-grant for each direct grant, and transfer anything she owns that the team depends on. Removal normally emails the person, so treat it as visible rather than silent, though delivery is skipped if they have opted out of notifications.
How do I see who has access to a shared AI agent skill?
Run goodeye skills grants my-skill --table for a readable list of grantee, type, role, whether it came via a team, and the version floor. Add --json when you also need granted_by and granted_at, which the table leaves out. You need to be the owner, or hold an admin grant, to read it. One limit matters if you are treating this as an audit: the listing has one row per grant, not per person. A team grant appears as a single row, and the individual members who reach the skill through it are never listed, so this is not a roster of everyone who can read the skill. It also shows current access only, so a revoked grant leaves no trace.