Agent System Cards
What does someone need to understand this complete agent deployment?
Reference notes by Min · Reviewed October 15, 2026
Definition
An agent system card is a maintained summary of a specific deployment, including its models, tools, data flows, permissions, evaluation evidence and oversight arrangements.
A model card describes an important component, but an agent’s behavior also depends on orchestration, retrieval, tools and credentials. A system card should explain how these parts are assembled in a particular deployment and where humans retain decision authority.
What it covers
- Boundary
- Describe the deployment, users, environment and dependencies.
- Authority
- List permitted actions, delegation and approval conditions.
- Evidence
- Identify evaluation conditions, results and unresolved limitations.
- Operation
- Name owners, monitoring, intervention and review triggers.
Choose the audience before choosing detail. A public summary may explain purposes and limitations; an internal operational version may link to access policies and recovery procedures. Maintain consistency between versions without publishing secrets or information that would expose affected people.
In practice
Practical design patterns by Min.
- Tie the card to a versioned deployment rather than a generic product name.
- Link claims to supporting evidence while protecting sensitive details.
- Update the card after changes that affect behavior or authority.
Claims should be specific enough to inspect. Instead of saying that human oversight exists, identify which actions require approval and what reviewers see. Instead of saying that the system is evaluated, state the relevant workflow version, test conditions and material gaps.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Documentation can cover the AI service
Arnold and colleagues propose FactSheets for AI services. This article adapts that service-level documentation idea to tools, permissions and ongoing agent operations.
Source: Arnold et al.: FactSheets: Increasing Trust in AI Services ↗
Component documentation remains useful
Model Cards provide structured model reporting; a deployment summary should incorporate relevant component evidence without assuming it covers the entire agent.
Working example
A support agent adds a refund tool
The existing card describes answering questions and drafting responses.
- Document refund limits, approvals, eligible accounts and external effects.
- Add evaluation evidence for mistakes, duplicate requests and attempted misuse.
- Identify who can suspend refunds and reconcile disputed transactions.
Why the controls matter
Adding refunds changes the support agent’s consequences even if its conversational interface remains identical. The card should record this expansion and the evidence used to approve it. A reader should be able to distinguish the current deployment from the earlier read-only service.
Common pitfalls
- Copying a model card without documenting tools or permissions.
- Listing controls as present without evidence they are enabled.
- Exposing secrets or sensitive infrastructure details in a public card.
Documentation can become stale faster than a release cycle. Assign an owner and connect updates to deployment review. A card is a navigation aid to evidence and responsibilities, not proof that every listed safeguard is effective.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Does the card describe the deployed authority?
- Which version and evidence support its claims?
- Who updates it when tools change?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- Arnold et al.: FactSheets: Increasing Trust in AI Services ↗Accessed October 15, 2026
- Mitchell et al.: Model Cards for Model Reporting ↗Accessed October 15, 2026