AI Agent Engineering Field Reference

This field reference condenses the book into decision aids for design, implementation, release, and incident response. It does not replace current provider documentation. Use it to ask the right questions, preserve the harness invariants, and identify missing evidence before granting authority or declaring a production agent ready.

What are the essential terms?

Which SDK should you start with?

This is not a permanent verdict. Evaluate current capabilities and your task using official docs.

Design review checklist

• Why an agent instead of code/workflow?
• Outcome and acceptance evidence defined?
• Identity and tenant derived from trusted context?
• Narrow tool contracts and risk metadata?
• Policy outside prompts and model output?
• State, checkpoint, and idempotency model?
• Independent stop conditions and phase budgets?
• Injection, exfiltration, and supply-chain threat model?
• Human approval bound to exact effects?
• Normalized events and provider-native trace references?
• Evaluation cases for success, failure, adversarial, and operations?
• Rollback, cancellation, reconciliation, and deletion paths?

Production readiness checklist

• Deterministic domain/tool/policy tests pass.
• Provider adapter contracts pass.
• Golden and adversarial suites meet hard gates.
• No unauthorized side effects or cross-tenant access.
• Crash/retry/resume produces at-most-once effects.
• Secrets/PII canaries absent from telemetry.
• Load/chaos tests meet SLOs.
• Image/dependencies scanned; SBOM and signature stored.
• Dashboards and actionable alerts exist.
• Approval and incident tabletop completed.
• Canary and rollback thresholds documented.

Incident checklist

1. Stop or quarantine affected route/tool/provider/prompt version.
2. Preserve events, traces, checkpoints, approvals, and external references.
3. Revoke credentials and restrict egress if exposure is possible.
4. Identify every attempted and completed side effect.
5. Reconcile authoritative systems; do not trust generated summaries.
6. Notify owners and affected parties under policy.
7. Restore with the smallest safe change or rollback.
8. Add regression and detection cases before closure.

What are the permanent harness invariants?

1. The model proposes; the harness authorizes.
2. Business truth lives outside conversation history.
3. Every side effect is scoped, idempotent, auditable, and verifiable.
4. Resumption preserves policy, budget, identity, and effect state.
5. Provider differences remain visible at the adapter boundary.
6. Critical safety requirements are hard gates, not average scores.
7. A prompt is never the only security control.

Ask your coding agent: “Review this design against the seven harness invariants. Cite concrete files and tests, list gaps by severity, and propose the smallest safe changes. Do not edit or call external systems until I approve the plan.”

Check your understanding

1. Which invariant protects authorization?
2. Which checklist items prove crash recovery?
3. What is the first action in a suspected agent incident?

Expert extension

Teach the system to another engineer using only the evidence pack and this reference. If they cannot predict a run, trace an effect, or operate an incident, improve the system documentation—not their confidence.

Official source index

• OpenAI Agents SDK guide
• OpenAI Agents SDK Python
• OpenAI Agents SDK TypeScript
• Claude Agent SDK overview
• Claude Agent SDK quickstart
• Claude Agent SDK documentation index