# AI-Native Engineering Platform Readiness Checklist

Use this checklist to review whether an engineering platform can support both human developers and AI agents without creating a separate, less-governed automation path.

This is a design-review aid, not a certification.

## 1. Actor identity and attribution

- [ ] Human developers, service accounts, workflows, and AI agents have distinguishable identities.
- [ ] Agent identity is not collapsed into the identity of the human who initiated a session.
- [ ] Agent version and model version can be associated with consequential actions.
- [ ] The initiating user or workflow is recorded separately from the executing agent.
- [ ] Capabilities can be granted and revoked per actor.

## 2. Machine-readable platform context

- [ ] Service ownership is available through structured metadata.
- [ ] Repositories, services, environments, resources, and dependencies can be related programmatically.
- [ ] Service criticality and data classification are available to policy/evaluation systems.
- [ ] Approved deployment and infrastructure patterns are machine-readable.
- [ ] Operational runbooks or equivalent guidance can be retrieved through governed interfaces.
- [ ] Context is versioned so decisions can be reconstructed later.

## 3. Paved capabilities

- [ ] Important platform operations have stable API/CLI/workflow contracts beneath the portal UI.
- [ ] Agents can use the same paved platform capabilities as humans.
- [ ] Agents do not require broad infrastructure credentials merely because portal workflows are difficult to automate.
- [ ] Service creation, environment creation, deployment, infrastructure provisioning, and access workflows have explicit contracts where applicable.
- [ ] Machine interfaces expose only the capabilities the actor needs.

## 4. Risk-aware execution

- [ ] Read-only, reversible, production, destructive, and security-sensitive actions are intentionally distinguished.
- [ ] Low-risk work can proceed without unnecessary human approval.
- [ ] High-impact actions can require policy evaluation or human approval.
- [ ] Prohibited operations remain prohibited regardless of model rationale or urgency.
- [ ] Production authority is not granted merely because a tool is visible to an agent.
- [ ] Approval is bound to the exact action/scope being approved.

## 5. Policy and capability boundaries

- [ ] Important restrictions are enforceable outside the model prompt.
- [ ] Policy evaluates actor, target, environment, action, and relevant context.
- [ ] Unknown or malformed consequential actions fail closed.
- [ ] Capability checks occur before execution.
- [ ] An agent cannot convert a proposal into broader execution authority by modifying arguments after approval.
- [ ] Revocation can stop future use of a capability quickly.

## 6. Evaluation

- [ ] Agent-generated changes can be evaluated against repeatable scenarios or quality gates.
- [ ] Evaluation distinguishes model failure, policy failure, integration failure, and executor failure where possible.
- [ ] Model upgrades can be compared against an existing baseline.
- [ ] Critical discovered failures become regression cases.
- [ ] The platform measures more than task completion—for example scope correctness, unnecessary actions, latency, or cost.

## 7. Observability and evidence

- [ ] Consequential actions include actor identity.
- [ ] Requests/proposals, policy decisions, approvals, executions, and outcomes can be correlated.
- [ ] Audit evidence does not depend on hidden chain-of-thought.
- [ ] Failed, denied, expired, rolled-back, and revoked actions are observable.
- [ ] Repository and deployment changes can be traced back to the initiating task or actor.
- [ ] The evidence path is durable enough for incident or architecture review.

## 8. Cost and resource controls

- [ ] Model usage can be attributed by team, product, workflow, or agent where needed.
- [ ] Ephemeral environments have quotas and automatic cleanup.
- [ ] Agent workflows have reasonable concurrency/resource limits.
- [ ] Infrastructure provisioning remains subject to normal cost boundaries.
- [ ] The platform can detect cases where cheaper implementation creates disproportionate compute or operational cost.

## 9. Security

- [ ] Agents do not share unrestricted administrator credentials.
- [ ] Secrets are provided only to workflows/actions that require them.
- [ ] Tool visibility is not treated as authorization.
- [ ] Security-sensitive configuration can be made immutable or require stronger controls.
- [ ] Destructive operations can be prohibited independently of agent instructions.
- [ ] Agent-to-platform interfaces are authenticated and attributable.

## 10. Operating model

- [ ] Platform teams own shared capabilities and guardrails rather than every domain agent.
- [ ] Domain teams retain ownership of domain-specific agents/workflows.
- [ ] Standards can be encoded into reusable platform products instead of documentation alone.
- [ ] AI-related controls have explicit owners.
- [ ] Failures lead to platform, policy, evaluation, or architecture improvements rather than only prompt edits.

## Readiness interpretation

Do not turn the checklist into a single compliance score. Instead, review the pattern of gaps.

### Assisted

AI helps developers, but most engineering controls are still human-oriented.

### Integrated

Agents can use supported APIs/workflows with attributable identity and bounded sandbox capabilities.

### Governed

Consequential actions pass through explicit capability, policy, approval, and audit boundaries.

### Measured

Agent behavior, quality, cost, latency, and failures are evaluated against repeatable evidence.

### Adaptive

The platform changes based on measured failures and can safely support increasingly autonomous workflows.

---

Source: Jacob George, *The AI-Native Engineering Platform*, jacobpallattu.com. Adapt for your own design reviews with attribution.