Version 1.0 · 2026-07-20
Agent Production Readiness White Paper
A practical framework for taking AI agents from demonstration to governed production, covering accountability, data, tool access, evaluation, cost, security, deployment, rollback and operating evidence.
Who it is for
Executives, product, security and engineering teams
Questions to resolve
- Whether the agent has a named owner and stop authority
- Whether tools enforce least privilege and human approval
- Whether failures, cost overruns and data anomalies fail closed
Reading guide
- 01 Problem and outcome definition
- 02 Data, privacy and permissions
- 03 Evals and failure paths
- 04 Security and FinOps gates
- 05 Deployment, health and rollback
- 06 Evidence, watchdog and acceptance
Chapter preview: 1. Define the operating outcome before choosing an agent
Start with the current workflow, decision ownership, cost of error and measurable outcome. Only then decide whether an agent is better than rules, conventional automation or a human process. “Improve efficiency” is not an acceptance criterion; cycle time, accuracy, review load, exception rate, unit cost and stop conditions are. These measures also belong in recurring operating reviews.
Action checks
- Evidence supports the baseline and target
- The owner can stop and roll back
- Not using an agent remains a valid option
DATA TABLE AND INTERPRETATION
Six hard controls for production readiness
All six controls need direct evidence. Any unknown, missing or failed control returns the whole decision to NOT READY.
Table listing six hard production controls for AI agents, the minimum evidence for each and the rule that blocks release.
Six hard controls for production readiness| Control | Minimum evidence | Blocking rule |
|---|
| Ownership and stop authority | Named owner, delegate and kill-switch rehearsal | Block if ownership or safe stop is missing |
|---|
| Data and permissions | Classification, purpose, least privilege and revocation record | Block on excess access or failed revocation |
|---|
| Evaluation and failure paths | Normal, boundary, hostile, timeout and duplicate tests | Block if a material failure does not fail closed |
|---|
| Security and cost | Threat model, scans, unit cost and stop threshold | Block unresolved high risk or budget breach |
|---|
| Release and recovery | Version identity, health check and rollback rehearsal | Block a mismatch or untested rollback |
|---|
| Monitoring and audit | Alerts, on-call, immutable events and recurring review | Block broken monitoring or unreconstructable evidence |
|---|
- Source
- FDE AI Agent Production Readiness White Paper v1.0, PAS v1.1 and IES v1.1
- As of
- 2026-07-20
- Unit
- hard-control requirement (6 total)
- Sample
- Not applicable: normative control model, not a market sample
- Method
- Normative synthesis of shared blocking conditions in this paper, PAS and IES into six non-overlapping control domains.
- Limitations
- This is not an industry benchmark or legal opinion; each organization must raise thresholds for its own risks and obligations.
Scope and limitations
This paper is a governance and technical decision framework, not legal advice, security certification or launch approval.
Version 1.0 · 2026-07-20
Designing an Enterprise AI Operating System
A practical design for connecting data, operational semantics, knowledge, policy, permissions, workflows, AI agents and audit evidence as a durable enterprise capability.
Who it is for
CEOs, CIOs, COOs, data and AI leaders
Questions to resolve
- Which enterprise concepts require shared semantics
- Which decisions should be made by people, rules or AI agents
- How to change models without losing institutional knowledge or business logic
Reading guide
- Enterprise Data
- Operational Ontology
- Business Knowledge Network
- Policy and Permission
- Workflow Engine
- Multi-Agent Runtime
- Trace and Audit
Chapter preview: 1. Start with enterprise problems and shared semantics
If teams disagree on the meaning of customer, case, risk, completion or revenue, AI accelerates confusion. Select high-value workflows, define core concepts, states, relationships and owners, then expose them to models and agents. Business owners govern this semantic layer; it must not be trapped in one vendor's prompts or vector store. Business and engineering teams should review shared semantics together.
Action checks
- Every concept has an owner and definition
- Semantic changes are versioned and impact-assessed
- Systems of record remain authoritative
DATA TABLE AND INTERPRETATION
EAIOS seven-layer responsibility and output matrix
Each of the seven layers needs an accepted output so the organization retains semantics, policy and accountability when models change.
Table listing the seven EAIOS layers, each layer's required output and acceptable evidence.
EAIOS seven-layer responsibility and output matrix| Layer | Required output | Acceptance evidence |
|---|
| Enterprise Data | Authoritative inventory and quality contracts | Owner, classification, lineage and quality measures |
|---|
| Operational Ontology | Shared concepts, relationships and events | Versioned terms and cross-functional approval |
|---|
| Business Knowledge Network | Rules, documents and decision context | Source, validity period and conflict handling |
|---|
| Policy and Permission | Purpose, roles and action boundaries | Policy tests and denial records |
|---|
| Workflow Engine | Retryable and compensating workflows | State, idempotency and failure rehearsal |
|---|
| Multi-Agent Runtime | Controlled roles and tool contracts | Evaluation, cost, authority and stop tests |
|---|
| Trace and Audit | End-to-end decision and change history | Immutable events, query and retention evidence |
|---|
- Source
- FDE AI EAIOS v1.0 and the FDE AI Governance Baseline
- As of
- 2026-07-20
- Unit
- architecture responsibility layer (7 total)
- Sample
- Not applicable: normative reference architecture, not an empirical sample
- Method
- Normative decomposition of enterprise AI into seven primary-responsibility layers following Governance First → Semantic First → Agent First.
- Limitations
- This is a responsibility model; it does not require seven products or seven teams.
Scope and limitations
The architecture must reflect the organization’s data, regulatory obligations, risks and existing systems. A generic blueprint cannot be applied unchanged.
Version 1.0 · 2026-07-20
FDE Skills and Career White Paper
Defines FDE as a verifiable set of capabilities: understand enterprise problems, shape decisions, deliver across systems, manage risk, measure outcomes and transfer knowledge.
Who it is for
AI engineers, consultants, product managers and career switchers
Questions to resolve
- Whether a portfolio exposes real constraints and tradeoffs
- Whether delivery includes KPIs, operating evidence and a tested rollback path
- Whether the person can connect business teams, engineering teams and users
Reading guide
- Future: identify change and opportunity
- Decision: turn ambiguity into testable choices
- Execution: deliver across data, product, models and organization
- Governance: permissions, safety, cost and evidence
- Adoption: enable durable team use and ownership
Chapter preview: 1. Define capability through real enterprise problems
An FDE interviews users and leaders, identifies the workflow, data, authority, incentives and risks behind a request, and turns ambiguity into testable options. Implementation is only part of the job; a complete delivery explains why, who carries risk and how success will be measured. Evidence should be understandable to someone outside the project.
Action checks
- Problem statements include constraints and non-goals
- Decision options expose tradeoffs
- Acceptance measures are defined before build
DATA TABLE AND INTERPRETATION
Four-level FDE capability evidence rubric
Titles, tenure and certificates cannot prove capability on their own; each capability must be judged from reproducible work evidence.
Table defining FDE capability evidence levels 0 through 3, observable evidence and the work each level may support.
Four-level FDE capability evidence rubric| Level | Observable evidence | Interpretation |
|---|
| 0 | Unproven | Claims, coursework or a tool list only | Do not assign production delivery on this evidence |
|---|
| 1 | Guided practice | Completes a small case with explicit steps | Ready for controlled learning work |
|---|
| 2 | Independent delivery | Frames the problem, tradeoffs, tests, risk and outcome | Ready for reviewed production work |
|---|
| 3 | Scalable practice | Creates reusable standards, leads collaboration and transfers ownership | Ready to own a system or cross-functional outcome |
|---|
- Source
- FDE AI Capability Governance Standard v1.0 and this white paper v1.0
- As of
- 2026-07-20
- Unit
- capability evidence level (0-3)
- Sample
- Not applicable: normative rubric, not a candidate-statistics sample
- Method
- Normative four-level rubric based on autonomy, evidence completeness, reproducibility and knowledge transfer.
- Limitations
- Do not use this rubric alone for hiring or rejection; combine it with job relevance, reasonable accommodation and multiple forms of evidence.
Scope and limitations
FDE AI does not guarantee employment, compensation or project outcomes. Guidance must reflect each person’s experience and current market conditions.