Agent ownership
When FDAI takes over an operational task, that task still needs an accountable person. Ownership maps each of the 15 agents to named people, so an escalation, a review, or a question always reaches someone who understands the domain. Ownership handover is how the knowledge those people carry gets written down and attached to the agent that now does the work.
This page explains the two-axis model you work in, what the ownership map guarantees, and how a ownership handover document becomes a reviewed change instead of a silent edit.
Authority boundary: Being an agent’s owner grants no FDAI permission. It never grants the executor identity, and it never widens what you can approve. Access and ownership are validated, approved, and audited as separate axes.
Two axes, not one
Section titled “Two axes, not one”New operators often assume that owning an agent means being allowed to run it. It doesn’t. FDAI keeps two independent questions apart.
| Question | Axis | Values |
|---|---|---|
| What may this person do in FDAI? | Access (RBAC) | Reader, Contributor, Approver, Owner, Break-Glass |
| Who answers for this agent’s domain? | Ownership | Final owner (final owner), Notified |
Most people sit in both models. An Approver who handles cost approvals may also be the accountable owner for Njord, the cost specialist. The two are still resolved separately, so removing someone from an approval group doesn’t quietly leave an agent unowned, and naming someone as an owner doesn’t quietly grant them approval rights.
What the ownership map guarantees
Section titled “What the ownership map guarantees”The map is a reviewed file in Git, not a runtime setting. It lists every agent and the people behind it.
- Every agent is mapped. All 15 agents appear in the map. The map won’t load if an agent has no accountable owner, unless that agent is explicitly recorded as running without a standing domain owner and the reason is written down.
- An agent can have several owners. Each agent maps to a list rather than to one person, and an entry can name an individual or a directory group. That’s how you express “the platform team owns this” without listing five people.
- FDAI itself needs an owner. At least one FDAI maintainer is required, and startup fails without one. Two is the recommendation, and a single FDAI maintainer raises a warning, because one person is a single point of failure for every escalation that has nowhere else to go.
- The FDAI maintainer is the last stop. An agent whose owners can’t be reached escalates to the FDAI maintainer rather than going unanswered.
Each entry carries a responsibility. An Final owner owner is answerable for the domain, and a Notified entry is kept informed without being on the hook. A newer schema adds ordered duties, so you can record who is primary, who is backup, and who is the escalation target.
When an owner goes stale
Section titled “When an owner goes stale”People change teams and accounts get deleted. FDAI watches for that instead of discovering it during an incident.
A scheduled check compares the map against your directory. An entry that no longer resolves to a live identity is reported as a stale owner. This is a warning, not a shutdown: the control plane keeps running, the stale entry appears in the ownership view, and an audit record is written when the state changes rather than on every check.
That distinction matters when you’re on call. A stale owner means the escalation path for that agent is broken and needs attention soon. It doesn’t mean FDAI stopped working.
How a ownership handover document becomes a change
Section titled “How a ownership handover document becomes a change”Ownership handover starts with a document someone already has: an on-call roster, a RACI chart, an org chart, a runbook, or a memo written on the way out. FDAI reads it, proposes a map change, and stops.
- Upload. You submit the document through the console’s knowledge-ownership handover form, or through the ingestion path directly. It passes the same safety inspection as any other upload.
- Extract. A deterministic extractor scans line by line for agent domain terms, responsibility markers, and people. A deployment can also bind an optional grounded interpreter; the upstream default holds for review. Every accepted claim cites its source, and an ungrounded proposal is discarded.
- Resolve. Named people are looked up in your directory. FDAI never guesses an identity. A name it can’t resolve is flagged as unresolved and left for a person to settle.
- Draft. Candidates below the confidence floor are set aside for human review. The result is an inert draft ownership map with warnings for unresolved people, held for review candidates, and agents without a confident accountable owner.
- Validate and propose. The draft must name only the fixed 15 agents, contain no access-role fields, and satisfy the ownership schema. When the governance path is enabled, a nonempty draft is published as one content-addressed, review-only pull request. A draft held for review or an empty draft opens no pull request, and retrying the same document doesn’t open a duplicate.
- Merge and activate. A person reviews that pull request and may merge it. The loader validates the complete map after merge before it becomes active. Rejection or invalid configuration leaves the previous map unchanged and preserves an audit trail for correction or revert.
The draft is never applied automatically, at any confidence level. That is the point: a document is evidence about who owned what, and evidence doesn’t get to rewrite an escalation path on its own.
To read a draft after upload, fetch it from the ingestion path:
GET /ingestion/uploads/{upload_id}/handover-draftWhere you do this in the console
Section titled “Where you do this in the console”Ownership lives under Agent oversight in the console, with views for the current map, human dependencies, knowledge ownership handover, approval routes, and mapping reviews.
The console is a reading and proposing surface. It shows you the ownership projection and lets you submit a ownership handover proposal, and it can’t write the ownership map itself. Every real change goes through the reviewed pull request.
Assigning a person to agents
Section titled “Assigning a person to agents”Beyond the map itself, an Owner can assemble an assignment case: one governed record that ties a person to a requested access role, the agent duties they would take on, and the knowledge goals that follow. A case moves through draft, review, ownership change, and activation, recording who requested it and who reviewed it at each step.
Two rules shape how this feels in practice:
- Someone else reviews it. The Owner who submits a case can’t be the Owner who approves it.
- The case coordinates, it doesn’t authorize. Access and ownership are still applied and audited as separate effects, so one form can request both without merging the two authorities.
Current status: Directory search, assignment-case records, the review flow, and the joined ownership view are implemented. The isolated membership and approved inverse paths are also source-connected, but observation mode never changes membership. Execution needs separate promotion, current independent approval and safeguards, and independent effect observation. The Console cannot bypass those checks. Operational evidence remains open; source completion is not a live access grant or permission for a manual workaround.
Collecting knowledge without burning people out
Section titled “Collecting knowledge without burning people out”Once someone is mapped to an agent, FDAI can ask them to fill gaps in what it knows. That invitation is deliberately rationed, because an operator who gets interrupted constantly stops answering.
- At most one invitation per session, and at most two proactive sessions in a week.
- One active session per person is capped at three unique turns and five non-sliding minutes.
- No invitation arrives while you’re handling an incident or a pending approval.
- You can answer, attach a document instead, snooze for a day, or decline.
Snoozing and declining are yours alone to decide. Accepting a knowledge goal on someone’s behalf needs an independent Owner, for the same reason a case needs a second reviewer.
English/Korean invitations and the separately reviewed removal lifecycle are implemented. Removal still requires current replacement coverage and fresh review; independent IAM removal precedes the reviewed old-duty change. Reusing knowledge never copies acceptance or approval. Live removal, recovery and adoption evidence remains separate from these source capabilities.
What good ownership looks like
Section titled “What good ownership looks like”- No agent is unowned, and any agent recorded as running without a standing owner has a written reason.
- Every agent has a backup, so one vacation doesn’t break an escalation path.
- No stale owners, checked continuously rather than at audit time.
- At least two FDAI maintainers, so the final escalation target is never one person.
- Ownership handover documents resolve to real people, with unresolved names settled rather than left in the draft.
Next steps
Section titled “Next steps”| To learn about | Read |
|---|---|
| How to collect actual speech and remaining operational evidence | Validate ownership handover |
| What each of the 15 agents is accountable for | The agent organization |
| How approval authority is granted and checked | Approvals and channels |
| How to inspect what an owner or an agent actually did | Read the audit log |
| The full agent ownership contract and map schema | Agent operational ownership |
| The runtime, recovery, and verification detail | Agent ownership lifecycle |