AI Agent Configuration Readiness
Treat an AI agent as a controlled configuration item and check whether its configuration is release-ready: model and version, system prompt, tools and permissions, knowledge sources, evaluation suite, approved Contexts of Use, and human oversight. Any missing mandatory element blocks approval deterministically — no approved Context of Use → not approved — because you cannot assure a configuration you cannot reconstruct. A scoping aid, not a validated assurance system.
OUTPUT
TIME
Limitations — read before you rely on this
- This is a scoping aid, not a validated system, and not a configuration-management system. Reproduce the configuration record in a controlled repository you own; a checklist result is not a configuration baseline.
- It checks whether each element is declared present — not whether what you captured is correct, current, or adequate. A defined-but-wrong system prompt still reads as Defined here; the depth of each element is yours to assure.
- Which elements are mandatory is SPEQ’s schema, not a regulator’s list. Your quality system may require more (or organize them differently); treat this as a starting frame to adapt, not a compliance checklist.
- It assesses a single agent configuration at a point in time. A model or prompt change produces a new configuration to re-check — that change-impact step is a separate assessment.
WHAT THIS CALCULATES
Whether an AI agent’s configuration is reconstructable and therefore approvable. Treating the agent as a controlled configuration item — model and version, system prompt, tools and permissions, knowledge sources, evaluation suite, approved Contexts of Use, human oversight — it checks each element’s state and returns a deterministic verdict: release-ready, conditional, or not-approved. Any missing mandatory element blocks approval, because you cannot assure a configuration you cannot describe.
THE METHOD
verdict = not-approved if any mandatory element is undefined, else conditional if any applicable element is undefined, else release-ready; completeness = defined ÷ applicable- mandatory
- an element required for a reconstructable configuration — identity, versions, system prompt, knowledge sources, eval suite, approved Context of Use, human oversight (and tool permissions once the agent has tools)
- applicable
- the elements in scope for this agent — every element except those marked genuinely not-applicable (N/A)
- defined
- the applicable elements that are actually specified and version-controlled
- completeness
- the fraction of applicable elements that are defined, in 0–100%
- verdict
- the deterministic outcome: release-ready, conditional (define the remaining optional elements), or not-approved (a mandatory element is missing)
Which elements are mandatory is SPEQ’s configuration schema expressing the epic’s determinism rules ("no approved Context of Use → not approved"), not a regulatory checklist. Tool permissions are mandatory only when the agent has tools. Monotonic: defining a missing element never worsens the verdict.
THE INPUTS, AND WHAT THEY MEAN
- Element state (Defined / N/A / Missing)
- For each configuration element, whether it is specified and version-controlled (Defined), legitimately not applicable to this agent (N/A), or absent (Missing). N/A removes an optional element from the completeness denominator; it cannot excuse a mandatory one.
- Whether the agent has tools
- Set by marking the Tools element Defined. It flips tool-permissions from optional to mandatory, because an agent that can act must have its permissions and their limits defined — expanding a permission later requires a change-impact assessment.
Is this agent’s configuration reconstructable and approvable?
Treat an AI agent as a controlled configuration item. Mark each element Defined, N/A, or Missing, and SPEQ returns whether the configuration is release-ready. Any missing mandatory element blocks approval deterministically — you cannot assure a configuration you cannot reconstruct, and no approved Context of Use means not approved.
- Agent identity
- Agent version
- Model + provider
- Model version
- System prompt
- Knowledge sources
- Evaluation suite
- Approved Contexts of Use
- Human oversight
- Prompt templates
- Tools
- Tool permissions
- Retrieval configuration
- Embedding model
- Guardrails & policies
- Monitoring
9 mandatory configuration elements are undefined (e.g. identity) — the configuration is not reconstructable, so it cannot be approved. Determinism, not judgment.
HOW TO READ THE OUTPUT
- Not-approved is a statement about reconstructability, not quality. A brilliant agent whose system prompt or knowledge sources are not captured cannot be assured, because a future reviewer cannot reproduce what it was — so the gate refuses to approve it.
- Conditional means the configuration is safe to reason about but not yet a complete record: every mandatory element is defined, but optional elements (retrieval config, guardrails, monitoring) are still worth capturing before the configuration is considered final.
- Use N/A honestly. A retrieval-augmented agent cannot mark knowledge sources N/A; a non-RAG agent legitimately can mark retrieval config and embedding model N/A. N/A narrows the denominator, so misusing it inflates completeness against you at audit.
- The verdict is the entry gate to assurance, not the whole of it. A release-ready configuration is one you can now assess for risk, evaluate, and monitor — it does not by itself mean the agent is validated.
WORKED EXAMPLE
A RAG regulatory copilot with tools. Everything is captured except the approved Contexts of Use, which have not been formally recorded yet.
- Model, version, system prompt
- Defined
- Tools + tool permissions
- Defined
- Knowledge sources, eval suite, oversight
- Defined
- Approved Contexts of Use
- Missing
RESULT
The configuration is almost complete and still not approvable: without a recorded approved Context of Use there is no answer to "approved for what?", so the deterministic rule blocks it regardless of how much else is in place. The fix is specific — record the Contexts of Use the copilot is approved for — after which the same configuration becomes release-ready.
REGULATORY BASIS
- FDA/EMA — Guiding Principles of Good AI Practice in Drug Development (Jan 2026)
- Frames the lifecycle and configuration control this registry supports; see SPEQ’s Good AI Practice page.
- ISPE GAMP 5 (2nd ed.) — A Risk-Based Approach to Compliant GxP Computerized Systems
- Supplies the configuration-management and version-control expectations that make a system’s behaviour reconstructable.
- ISO/IEC 42001:2023 — AI management systems
- The management-system requirement to control AI system configurations and changes across the lifecycle.