AIFC-023: AI as Team Member
Status: Draft 0.1 Standard: AI-First Community Standard Abbreviation: AIFC Builds on:
- AIFC-000 Manifesto of an AI-first community
- AIFC-001 Core Concepts
- AIFC-002 Community Model
- AIFC-010 Knowledge Structure
- AIFC-011 Operational DNA
- AIFC-020 Human-Managed AI
- AIFC-021 AI as External Expert Capacity
- AIFC-022 AI-NDA Boundary
Purpose of this document: Define AI as Team Member: how an AI agent may be involved as a governed team member with role, scope, permissions, limits, human owner, auditability, value measurement, approval rules, fallback, and shutdown capability.
1. Purpose of this document
This document describes how an AIFC community may involve an AI agent as a team member.
An AI agent is not a human.
It does not have human accountability, value judgement, social grounding, or real membership in the community.
It may, however, perform recurring roles similar to team roles:
- analyze,
- summarize,
- propose,
- review,
- flag issues,
- prepare documents,
- create change proposals,
- validate structure,
- maintain a knowledge base,
- help with backlog work,
- support decision-making,
- execute approved low-risk steps.
AIFC therefore allows an AI agent to be understood as a governed team member, but only if its boundaries are explicit and accountability remains with humans or the community.
2. Core principle
The core principle of this document is:
AI may act as a team member only when its role, scope, permissions, owner and limits are explicit.
An AI agent may be a useful team collaborator.
It must not become an invisible, unlimited, or unaccountable actor inside the community.
AIFC therefore says:
No AI team member without role, owner, boundary and audit.
3. Definition
AI as Team Member is a governed way to involve an AI agent in community work.
An AI team member has:
- role,
- purpose,
- scope,
- human or community owner,
- allowed inputs,
- allowed actions,
- forbidden actions,
- access permissions,
- AI-NDA Boundary,
- approval rules,
- audit trail,
- value measurement,
- fallback,
- exit or shutdown path.
An AI team member is not an autonomous community member in the sense of human accountability.
It is governed work capacity.
4. Why this concept matters
AI is often used informally:
- someone opens a chat,
- inserts data,
- asks for a proposal,
- copies the output,
- the decision moves forward,
- but nowhere is it clear who used AI, why, with what permission, and with what impact.
This is dangerous when AI begins to influence team work repeatedly.
If AI performs a recurring role, it must be governed as a role.
Just as a human in a team does not have unlimited access and unlimited decision authority, an AI agent must not have unlimited possibilities only because it is useful.
Minimum requirement
If an AI agent performs a recurring or significant team role, it must be defined as an AI team member with role, owner, and rules.
5. AI team member vs AI tool
AIFC distinguishes between an ordinary AI tool and an AI team member.
AI tool
An AI tool is used ad hoc for a specific task.
Examples:
- one-time summary of public text,
- draft wording for an email,
- translation of public text,
- simple brainstorm support.
AI team member
An AI team member has a recurring role in the community.
Examples:
- Knowledge Maintenance Agent,
- Backlog Refinement Agent,
- Security Review Assistant,
- UX Review Agent,
- AI Retrospective Agent,
- Change Proposal Analyst,
- Documentation Cleanup Agent,
- Support Triage Agent,
- Code Review Assistant,
- Community Interface Monitor.
Minimum requirement
If AI repeatedly performs a defined type of work, it should move from ad hoc tool use into a governed AI team member model.
6. Role definition
Every AI team member must have a clearly defined role.
The role should answer:
- Why does the agent exist?
- What purpose does it serve?
- What work does it perform?
- What types of outputs does it create?
- Whom does it help?
- What problem does it solve?
- What values must it respect?
- What boundaries must it not cross?
Example:
Role:
Knowledge Maintenance Agent
Purpose:
Help the community detect outdated, duplicated, ownerless or structurally invalid knowledge artefacts and create maintenance proposals.
Not responsible for:
Approving changes, deleting active knowledge, changing sensitivity or updating Operational DNA without review.
Minimum requirement
An AI team member must have its role recorded in the source of truth.
7. Human owner
Every AI team member must have a human or community owner.
The owner is accountable for:
- agent purpose,
- scope,
- permissions,
- AI-NDA Boundary,
- outputs,
- review,
- value measurement,
- costs,
- risks,
- shutdown,
- role changes,
- agent skill updates,
- incident handling.
An AI agent must not be its own owner.
Minimum requirement
An AI team member without an owner is not AIFC-compatible.
8. Scope
Scope defines where and how an AI team member may work.
It may include:
- knowledge domains,
- projects,
- teams,
- document types,
- data types,
- workflows,
- systems,
- tools,
- tasks,
- time limits,
- autonomy level.
Scope prevents the agent from gradually expanding into areas for which it was not approved.
Minimum requirement
An AI team member must have defined scope and rules for changing it.
9. Allowed inputs
An AI team member must have defined allowed inputs.
Examples:
- public documents,
- selected internal knowledge artefacts,
- approved workflow descriptions,
- submitted change proposals,
- anonymized support tickets,
- backlog items,
- approved design screenshots,
- non-restricted decision records.
Allowed inputs must match the AI-NDA Boundary.
Minimum requirement
An AI team member must define what inputs it may process.
10. Forbidden inputs
An AI team member must have defined forbidden inputs.
Examples:
- secrets,
- credentials,
- raw personal data,
- unrestricted customer data,
- restricted HR records,
- legally privileged documents,
- security vulnerabilities without approval,
- unapproved Operational DNA,
- documents outside scope.
Forbidden inputs must be protected by rules and, where possible, technically.
Minimum requirement
An AI team member must define what inputs it must not process.
11. Allowed actions
An AI team member must have clearly defined allowed actions.
Examples:
- summarize,
- classify,
- detect missing metadata,
- propose cleanup,
- draft change proposal,
- suggest decision level,
- prepare review checklist,
- identify duplicate content,
- generate draft skill update,
- create risk note,
- prepare decision support,
- validate structure,
- create maintenance task draft.
Allowed actions may differ by autonomy level.
Minimum requirement
An AI team member must explicitly describe its allowed actions.
12. Forbidden actions
An AI team member must have clearly defined forbidden actions.
Examples:
- approve significant change,
- change active workflow without review,
- delete source of truth content,
- change sensitivity classification,
- access data outside the AI-NDA Boundary,
- publish external content without approval,
- make a financial commitment,
- decide a values conflict,
- change Operational DNA without owner review,
- update permissions,
- hide uncertainty,
- store restricted content in agent memory without approval.
Minimum requirement
An AI team member must explicitly describe its forbidden actions.
13. Permissions
An AI team member must have access permissions governed by the principles:
least privilege
need to know
purpose limitation
auditability
revocation
Permissions may be:
- read-only,
- propose-only,
- draft-write,
- write-with-approval,
- execute-approved-low-risk-actions,
- no-access-to-restricted-data,
- no-access-to-operational-dna,
- temporary-access.
Minimum requirement
An AI team member with access to non-public know-how must have defined and auditable permissions.
14. Autonomy level
An AI team member must have a defined autonomy level.
Recommended scale:
0 % - no autonomous action
25 % - proposes only
50 % - creates drafts, human approves
75 % - executes approved low-risk actions with review gates
100 % - operates autonomously only inside strict pre-approved boundaries
Autonomy must be contextual.
The same agent may have:
- 75 % autonomy for detecting missing metadata,
- 50 % autonomy for drafting change proposals,
- 0 % autonomy for changing Operational DNA.
Minimum requirement
An AI team member must have autonomy defined by action type.
15. Approval rules
An AI team member must know when approval is required.
Approval may be required for:
- changing the source of truth,
- publishing external output,
- working with restricted data,
- changing a workflow,
- changing the AI-NDA Boundary,
- changing Operational DNA,
- creating a decision record,
- proposing a change to values interpretation,
- significant impact on another community.
Approval must be traceable.
Minimum requirement
An AI team member must have rules defining which outputs and actions require human or community approval.
16. Output types
An AI team member must have defined output types.
Examples:
- summary,
- draft,
- analysis,
- recommendation,
- change proposal,
- maintenance proposal,
- risk note,
- decision support,
- skill update proposal,
- validation report,
- incident signal,
- backlog item draft.
Output must be marked by status.
AI output is not automatically approved knowledge.
Minimum requirement
AI team member output must be clearly distinguishable from approved source of truth.
17. Write-back rules
An AI team member must have rules for writing back into the source of truth.
It may, for example, have permission to:
- create a draft artefact,
- create a proposal,
- add a comment,
- mark an issue,
- create a maintenance task,
- prepare a pull request,
- update metadata in a low-risk area,
- or only propose a change.
For critical content, write-back must be approved.
Minimum requirement
An AI team member must not write into the active source of truth without defined write-back rules.
18. Memory rules
An AI team member may or may not have memory.
Agent memory is risky if it contains:
- restricted data,
- Operational DNA,
- customer information,
- decision logic,
- skills,
- internal strategy.
Memory rules must define:
- what is stored,
- what is not stored,
- who can see the memory,
- how the memory is deleted,
- how it is exported,
- how it is audited,
- how memory is prevented from replacing the source of truth.
Minimum requirement
AI team member memory must not be an authoritative source of truth.
19. Source of truth relationship
An AI team member must work in relation to the source of truth.
This means it:
- reads approved knowledge according to permissions,
- distinguishes active, draft, deprecated, and rejected content,
- generates proposals as proposals,
- does not store critical know-how only in chat or memory,
- links outputs to decision records,
- returns significant know-how to the source of truth through review.
An AI team member must not create a parallel informal knowledge base.
Minimum requirement
An AI team member must have a defined relationship to the source of truth.
20. Human Cockpit Layer relationship
The Human Cockpit Layer must make AI team members visible.
Accountable community members should see:
- agent name or identity,
- role,
- owner,
- scope,
- status,
- autonomy level,
- AI-NDA Boundary,
- permissions,
- latest outputs,
- pending approvals,
- risks,
- cost usage,
- value contribution,
- incidents,
- memory status,
- fallback,
- shutdown option.
Without this visibility, AI agents may become invisible labor without governance.
Minimum requirement
Significant AI team members must be human-visible in the Human Cockpit Layer or an equivalent governance interface.
21. Naming and identity
An AI team member must have a clear identity.
Identity may include:
- name,
- role ID,
- owner,
- version,
- scope,
- status.
Example:
Knowledge Maintenance Agent
id: agent_kma_4f91
version: 0.3
owner: knowledge-owner
status: active
The agent’s name should not create an illusion of human accountability.
Excessively anthropomorphic presentation may hide the fact that accountability belongs to a human or the community.
Minimum requirement
An AI team member must have a stable identity and must not hide its human owner.
22. Onboarding of AI team member
An AI team member must be introduced into the team in a governed way.
Onboarding may include:
- role definition,
- scope definition,
- permission setup,
- owner assignment,
- AI-NDA Boundary approval,
- definition of allowed and forbidden actions,
- test mode,
- output review,
- cost limit,
- fallback setup,
- communication to the team about what the agent may and may not do.
Minimum requirement
An AI team member with significant impact must not be introduced without an onboarding record.
23. Offboarding of AI team member
It must be possible to safely turn off or remove an AI team member.
Offboarding must address:
- removing permissions,
- closing open tasks,
- exporting or deleting memory,
- recording relevant know-how in the source of truth,
- evaluating value,
- checking dependency,
- disconnecting tools,
- archiving the agent record,
- incident check.
Minimum requirement
An AI team member must have an offboarding mechanism.
24. Performance and value measurement
An AI team member must be evaluated by value, not only by activity.
It is not enough to measure:
- how much text it created,
- how many proposals it submitted,
- how many tickets it processed.
What matters is:
- how many useful proposals were accepted,
- how much debt it helped reduce,
- how many risks it detected,
- how much review work it added,
- how much noise it created,
- how much AI dependency it caused,
- how much know-how returned to the source of truth,
- whether it improved or weakened human capability.
Minimum requirement
A significant AI team member must be regularly evaluated for value, cost, risk, and dependency.
25. Cost visibility
An AI team member consumes resources.
It may consume:
- tokens,
- API costs,
- compute,
- human review time,
- attention,
- governance capacity,
- security capacity.
Cost must be visible.
If an AI team member has no measured consumption, the community cannot decide whether its value is worth its cost.
Minimum requirement
A significant AI team member must have cost visibility or at least a cost estimate.
26. Risk management
An AI team member may create risks.
Examples:
- incorrect proposals,
- hallucinations,
- work with inappropriate data,
- access outside scope,
- excessive autonomy,
- hidden decision-making,
- AI dependency,
- AI lock-in,
- knowledge leakage,
- over-trust,
- under-review,
- loss of human capability,
- change in team behavior.
Minimum requirement
An AI team member with access to non-public data, the source of truth, or tools must have a risk assessment.
27. AI team member as proposer
An AI team member may be a strong source of change proposals.
It may propose:
- cleanup,
- new workflow,
- priority change,
- skill update,
- risk mitigation,
- AI dependency reduction,
- fallback,
- change to the AI-NDA Boundary,
- change to operating mode,
- maintenance backlog item.
But a proposal is not a decision.
Minimum requirement
AI-generated change proposals must be marked as AI-generated and pass through a governance lifecycle.
28. AI team member in decision support
An AI team member may prepare decision support material.
It may:
- summarize context,
- compare alternatives,
- estimate risks,
- identify affected values,
- propose decision level,
- prepare a decision record draft.
An AI team member must not decide silently by having its recommendation automatically accepted without review.
Minimum requirement
A decision support agent must clearly distinguish analysis, recommendation, and decision.
29. AI team member in maintenance
A maintenance agent may help care for the knowledge base and workflows.
It may look for:
- outdated artefacts,
- missing owners,
- missing review,
- duplicate content,
- metadata conflicts,
- deprecated content still referenced,
- AI workflow without fallback,
- Operational DNA without owner,
- restricted content with unsafe AI access.
What a community does not maintain tends to degrade or create debt.
An AI maintenance agent may speed up this care, but it does not own accountability for the knowledge base.
Minimum requirement
A maintenance agent may propose and prepare maintenance, but critical changes must have owner review.
30. AI team member in support
A support agent may help with triage, responses, summaries, and pattern detection.
Risks of a support agent:
- work with personal data,
- hallucinations toward customers,
- unauthorized commitments,
- reputational impact,
- loss of human contact with customer reality,
- invisible customer signal.
Minimum requirement
A support AI team member must have clear rules for customer-facing outputs, data sensitivity, and escalation.
31. AI team member in development
A development agent may help with:
- code proposals,
- tests,
- refactoring,
- documentation,
- code review,
- pattern detection,
- technical solution design.
Risks:
- developer AI dependency,
- poor understanding of architecture,
- security weaknesses,
- unmaintained changes,
- loss of junior learning,
- vendor or model dependency.
Minimum requirement
A development AI team member must support human capability, not replace it. Critical changes must have review and a link to the source of truth.
32. AI team member and human capability
An AI team member must not cause people to lose the ability to understand or perform work.
AI may do work faster.
But the community must maintain:
- ability to assign the work,
- ability to review the output,
- ability to fix an error,
- ability to continue without AI,
- ability to teach a new member,
- ability to understand its own system.
If an AI team member speeds up the team while removing human learning, it creates hidden debt.
Minimum requirement
An AI team member must be regularly evaluated for its impact on the Human Capability Reserve.
33. AI team member and AI-NDA Boundary
An AI team member must work inside the AI-NDA Boundary.
If the following change:
- role,
- data,
- scope,
- model,
- vendor,
- memory,
- output type,
- autonomy level,
the boundary may need to be updated.
Minimum requirement
An AI team member must not process non-public know-how outside an approved AI-NDA Boundary.
34. AI team member and Operational DNA
An AI team member may access Operational DNA only if this is explicitly approved.
Operational DNA access requires:
- explicit purpose,
- limited scope,
- owner,
- audit,
- AI-NDA Boundary,
- memory rules,
- output review,
- exit strategy,
- fallback.
Minimum requirement
An AI team member with access to Operational DNA must be marked as a high-risk or critical agent.
35. AI team member record
AIFC recommends using an agent record for an AI team member.
Example metadata:
ai_team_member:
id:
name:
role:
status: draft | proposed | active | paused | deprecated | retired | revoked
owner:
purpose:
scope:
allowed_inputs:
forbidden_inputs:
allowed_actions:
forbidden_actions:
permissions:
autonomy_level:
approval_rules:
ai_nda_boundary:
memory_allowed: true | false
memory_rules:
source_of_truth_access:
read: true | false
write: none | draft | proposal | approved_low_risk | active_with_approval
operational_dna_access: true | false
cost_limit:
risk_level:
review_cycle:
last_reviewed:
fallback:
offboarding_plan:
This structure is illustrative.
The final schema should be defined in the agent-actionable layer of the standard.
36. Anti-patterns
AIFC rejects the following anti-patterns.
36.1 AI agent without owner
An agent works in the team, but nobody is accountable for it.
36.2 AI agent without role
It is unclear why the agent exists.
36.3 AI agent with unlimited scope
The agent gradually gains access to everything.
36.4 AI agent with hidden permissions
The team does not know what the agent may read or change.
36.5 AI agent as hidden decision maker
AI recommendations are automatically accepted as decisions in practice.
36.6 AI agent memory as source of truth
The agent remembers important know-how that is not recorded in the source of truth.
36.7 AI agent without offboarding
The agent cannot be safely turned off, removed, or replaced.
36.8 AI agent without cost visibility
The agent consumes resources, but nobody knows how much and with what value.
36.9 AI agent causing human degradation
The agent speeds up work, but people lose the ability to understand or perform it.
36.10 AI agent anthropomorphism
The agent is presented in a way that hides the absence of human accountability.
37. Minimal requirements
In the area of AI as Team Member, an AIFC community must at minimum:
- Give an AI team member a clear role.
- Give an AI team member a human or community owner.
- Define the AI team member’s scope.
- Define allowed inputs.
- Define forbidden inputs.
- Define allowed actions.
- Define forbidden actions.
- Define permissions.
- Define autonomy level.
- Define approval rules.
- Distinguish AI outputs from approved source of truth.
- Define write-back rules.
- Ensure AI memory is not an authoritative source of truth.
- Connect the AI team member to the source of truth.
- Make a significant AI team member visible in the Human Cockpit Layer or governance interface.
- Provide an onboarding mechanism.
- Provide an offboarding mechanism.
- Give a significant AI team member cost visibility.
- Give an AI team member with non-public data an AI-NDA Boundary.
- Give an AI team member with Operational DNA access explicit approval and audit.
- Process AI-generated change proposals through a governance lifecycle.
- Evaluate AI team members for their impact on the Human Capability Reserve.
38. Summary
An AI team member is governed AI work capacity inside the community.
It can significantly help with work, knowledge, maintenance, proposals, decision support, and system learning.
But an AI team member must not be an invisible actor without boundaries.
AIFC therefore says:
Give AI a role.
Give it boundaries.
Give it an owner.
Give it audit.
Give humans the decision.
Keep knowledge in the source of truth.
Keep the community capable without it.
An AI agent may be a member of the work system.
It must not become the owner of the community.
AI as Team Member turns AI agents into governed community roles.