# Agent platform engineering **Agentic Engineering Field Curriculum · Edition 2026.08 · Reviewed 2026-08-10** Specify the identity, substrate, context, tool, orchestration, verification, evidence, and lifecycle services that bounded agents require, as contracts an independent reviewer can challenge. Level: advanced · Designed for Architect, Platform, Risk, Operations · Estimated study: 10 hours · 7 finite stages Canonical page: https://aisdlc.ai/agentic-engineering/learn/agent-platform-engineering ## 01 · Specify the execution substrate **Driving question:** Where does agent work actually take effect, and what stops a failed run from reaching anything else? Specify isolated workspaces, scoped credentials, controlled egress, and reproducible recovery for every agent run. ### Learning objectives - Separate the layer that reasons from the layer where actions take effect. - Specify workspace, filesystem, process, and network isolation for a stated risk tier. - Inject credentials per run with an expiry so no run holds standing secrets. - Define snapshot, teardown, and recovery behavior for an interrupted run. ### Study sequence 1. **[The layer where actions take effect](/agentic-engineering/execution-substrate)** — read, 16 min. Fix the boundary between reasoning and consequence first. 2. **[Match isolation strength to blast radius](/agentic-engineering/sandbox)** — compare, 20 min. Choose isolation strength from what a failed run could reach. 3. **[Write one environment contract](/control-plane-lab)** — practice, 30 min. Turn isolation intent into a written contract inside the lab's simulation boundary. ### Field exercise Write the substrate contract for one agent workload and show what a failed or hostile run cannot reach. **Deliverable:** A substrate contract carrying isolation boundaries, credential handling, and a recovery procedure. **Independent challenge:** A platform reviewer who did not draft the contract attempts to name an escape path — a shared filesystem, an ambient credential, or an open egress route — that the written contract fails to close, and records the finding without oral explanation from the author. **Evidence to retain** - Substrate contract - Isolation boundary map - Credential lifecycle note - Recovery procedure - Residual exposure list **Connected knowledge** - [Agent execution substrate](https://aisdlc.ai/agentic-engineering/execution-substrate) - [Sandbox](https://aisdlc.ai/agentic-engineering/sandbox) - [Deterministic containment](https://aisdlc.ai/agentic-engineering/deterministic-containment) - [Harness engineering](https://aisdlc.ai/agentic-engineering/harness-engineering) - [Risk-tiered autonomy](https://aisdlc.ai/agentic-engineering/risk-tiered-autonomy) **Connected Insights** - [Harness engineering is platform engineering](https://aisdlc.ai/insights/harness-engineering-is-platform-engineering) - [The model is not the architecture](https://aisdlc.ai/insights/the-model-is-not-the-architecture) ## 02 · Give every agent standing **Driving question:** Whose authority does an agent act under, and what happens to that standing when nobody renews it? Design an identity record that binds each agent to a purpose, a sponsor, an accountable owner, scoped permissions, and an expiry that removes standing by default. ### Learning objectives - Separate agent identity from the human account or shared service account it borrows today. - Bind delegated permission to a stated purpose and a named accountable owner. - Treat issuance, renewal, suspension, and revocation as one lifecycle rather than an onboarding step. - Record what an agent may never do regardless of who asks. ### Study sequence 1. **[Identity and delegated authority](/agentic-engineering/agent-identity)** — read, 15 min. Establish standing as a platform service before any permission is attached to it. 2. **[From one agent to the estate register](/agentic-engineering/agent-estate-governance)** — read, 18 min. Scale one identity record to a register of every agent and owner. 3. **[Draft an identity record with an expiry](/agent-estate)** — practice, 28 min. Make sponsor, owner, purpose, scope, and expiry concrete for one agent. ### Field exercise Write the identity record for one agent so that its standing lapses unless a named human renews it. **Deliverable:** An identity record carrying purpose, sponsorship, ownership, permission scope, expiry, and revocation path. **Independent challenge:** A risk reviewer who did not write the record attempts to find one permission the stated purpose does not justify and one path by which an orphaned agent would keep running after its expiry lapses, and records both findings. **Evidence to retain** - Identity record - Permission scope statement - Sponsor and owner attestation - Expiry and renewal rule - Revocation runbook **Connected knowledge** - [Agent identity & delegated authority](https://aisdlc.ai/agentic-engineering/agent-identity) - [Agent estate governance](https://aisdlc.ai/agentic-engineering/agent-estate-governance) - [Human accountability](https://aisdlc.ai/agentic-engineering/human-accountability) - [Continuous recertification & retirement](https://aisdlc.ai/agentic-engineering/continuous-recertification-retirement) - [Risk-tiered autonomy](https://aisdlc.ai/agentic-engineering/risk-tiered-autonomy) **Connected Insights** - [Every agent is a governed principal](https://aisdlc.ai/insights/every-agent-is-a-governed-principal) ## 03 · Version context and memory **Driving question:** Which text in an agent's window is trusted instruction, and which is untrusted data that arrived from somewhere else? Design context assembly so instructions, retrieval, and working state carry a version, a provenance record, a trust class, and a retention rule. ### Learning objectives - Classify every context source as trusted instruction or untrusted data at assembly time. - Version instructions and retrieval sets so a past run can be reconstructed later. - Set retention and expiry for memory that would otherwise carry stale or poisoned content forward. - Define how a compromised source is detected and removed from future runs. ### Study sequence 1. **[Context is a runtime system](/insights/context-is-a-runtime-system)** — read, 16 min. Treat the context window as versioned infrastructure, not a prompt. 2. **[Instruction and data at the same boundary](/agentic-engineering/instruction-data-trust-boundary)** — compare, 20 min. Separate what the platform authored from what the agent read. 3. **[Write a context manifest for one run](/agentic-engineering/context-engineering)** — practice, 30 min. Make every source, version, and trust class inspectable after the run. ### Field exercise Assemble one agent run's context from a written manifest and mark the trust class and retention of every source. **Deliverable:** A context manifest with source versions, trust classes, retention rules, and a removal path. **Independent challenge:** A reviewer reconstructs the same context from the manifest alone and challenges any source whose version, origin, or trust class cannot be established. **Evidence to retain** - Context manifest - Trust classification table - Instruction version record - Retention and expiry rule - Compromised-source removal note **Connected knowledge** - [Context engineering](https://aisdlc.ai/agentic-engineering/context-engineering) - [Instruction–data trust boundary](https://aisdlc.ai/agentic-engineering/instruction-data-trust-boundary) - [Durable project memory](https://aisdlc.ai/agentic-engineering/durable-memory) - [Working state](https://aisdlc.ai/agentic-engineering/working-state) - [Retrieval-augmented generation](https://aisdlc.ai/agentic-engineering/retrieval-augmented-generation) - [Context hygiene](https://aisdlc.ai/agentic-engineering/context-hygiene) **Connected Insights** - [Context is a runtime system](https://aisdlc.ai/insights/context-is-a-runtime-system) ## 04 · Draw the tool boundary **Driving question:** What separates an agent that can read a system, one that can propose a change, and one that can commit it? Design typed tool contracts that separate inspect, propose, execute, and commit capability, each with its own authorization and audit record. ### Learning objectives - Split one broad convenience tool into distinct inspect, propose, execute, and commit capabilities. - Type inputs and outputs so an out-of-scope call fails at the contract rather than at the system. - Attach authorization, rate limits, and an audit record to every capability that changes state. - Record refusals as carefully as successful calls. ### Study sequence 1. **[Where reasoning stops and action starts](/agentic-engineering/tools-and-protocols)** — read, 15 min. Establish the contract surface as the last deterministically enforceable boundary. 2. **[Four capability classes behind one endpoint](/agentic-engineering/tool-calling)** — compare, 18 min. Show what changes when inspect, propose, execute, and commit stop sharing a single permission. 3. **[Write a typed tool contract](/policy-pack)** — practice, 30 min. Push scope, authorization, and audit into the interface instead of the instructions. ### Field exercise Take one broad tool an agent would use and split it into separately authorized capabilities with typed contracts. **Deliverable:** A tool contract set with typed schemas, an authorization matrix, and audit fields. **Independent challenge:** A reviewer proposes an out-of-scope call for each capability and confirms the written contract rejects it without depending on model cooperation. **Evidence to retain** - Capability split - Typed schemas - Authorization matrix - Refusal cases - Audit record fields **Connected knowledge** - [Tools, skills & protocols](https://aisdlc.ai/agentic-engineering/tools-and-protocols) - [Tool calling](https://aisdlc.ai/agentic-engineering/tool-calling) - [Model Context Protocol](https://aisdlc.ai/agentic-engineering/model-context-protocol) - [Structured output](https://aisdlc.ai/agentic-engineering/structured-output) - [Runtime policy enforcement](https://aisdlc.ai/agentic-engineering/runtime-policy-enforcement) **Connected Insights** - [Every agent is a governed principal](https://aisdlc.ai/insights/every-agent-is-a-governed-principal) ## 05 · Design durable runs **Driving question:** What happens to a multi-step agent run when a step fails outside a supervised window? Design multi-step agent work with durable state, bounded retries, explicit handoffs, spend and time budgets, and a finite set of terminal dispositions. ### Learning objectives - Persist run state at step boundaries so a failure resumes rather than restarts. - Bound retries, elapsed time, and spend so an unproductive run terminates instead of looping. - Define every handoff as an explicit contract naming the receiving owner and the passed state. - Enumerate terminal dispositions so no run ends in an undefined state. - Bound queue depth and admission so backlogged work is refused rather than accumulated. ### Study sequence 1. **[What must survive a crash](/agentic-engineering/durable-execution)** — read, 16 min. Decide what state must survive a crash before designing multi-step runs. 2. **[Supervisor, handoff, and queue models](/agentic-engineering/orchestrator-supervisor)** — compare, 18 min. Choose a coordination shape from its failure behavior. 3. **[Set budgets and terminal dispositions](/control-plane-lab)** — practice, 32 min. Remove the undefined ending that turns a stuck run unbounded, in simulation. ### Field exercise Design the run ledger for one multi-step agent workflow and walk it through a deliberate mid-run failure. **Deliverable:** A run ledger design with budgets, handoff contracts, terminal dispositions, and a recorded failure walkthrough. **Independent challenge:** A reviewer stops the run at an arbitrary step and states from the ledger alone what happened, what resumes, and what is now owed to a human. **Evidence to retain** - Run ledger schema - Budget settings - Handoff contracts - Terminal disposition list - Failure walkthrough record **Connected knowledge** - [Durable execution](https://aisdlc.ai/agentic-engineering/durable-execution) - [Orchestrator or supervisor agent](https://aisdlc.ai/agentic-engineering/orchestrator-supervisor) - [Agent handoff](https://aisdlc.ai/agentic-engineering/agent-handoff) - [Goal and exit condition](https://aisdlc.ai/agentic-engineering/goal-exit-condition) - [Multi-agent system](https://aisdlc.ai/agentic-engineering/multi-agent-system) **Connected Insights** - [Harness engineering is platform engineering](https://aisdlc.ai/insights/harness-engineering-is-platform-engineering) - [Own the speed](https://aisdlc.ai/insights/own-the-speed) ## 06 · Design the verifier plane **Driving question:** At which moments can a check still stop the work, and which checks only record what already happened? Design independently owned preventive, inline, gate, and continuous checks so that authority to stop the work exists before the point of consequence. ### Learning objectives - Place each check by control timing rather than by tooling convenience. - Keep verifier ownership separate from the agent and the team whose work it challenges. - Combine deterministic checks with model-based challenge instead of choosing one exclusively. - Route disagreement to a named human rather than resolving it automatically. ### Study sequence 1. **[Verification is a plane, not a phase](/insights/verification-is-a-plane-not-a-phase)** — read, 15 min. Separate the four control timings before choosing any checking tool. 2. **[A check that records against a check that refuses](/agentic-engineering/observability-control)** — compare, 20 min. Locate which layers hold block authority and which only report after the fact. 3. **[Place four checks around one run](/assurance-case)** — practice, 32 min. Test whether stopping authority exists before the moment of consequence. ### Field exercise Design the verifier plane for one agent workload and show which checks can still refuse the work. **Deliverable:** A verifier plane map with owners, triggers, scope, block authority, and escalation paths. **Independent challenge:** An independent reviewer submits a deliberately non-compliant candidate and records which check refuses it and which only reports it afterward. **Evidence to retain** - Verifier plane map - Owner assignments - Block authority statement - Non-compliant candidate walkthrough - Escalation record **Connected knowledge** - [Independent verifier systems](https://aisdlc.ai/agentic-engineering/multi-agent-verification) - [Observability & control](https://aisdlc.ai/agentic-engineering/observability-control) - [Guardrail](https://aisdlc.ai/agentic-engineering/guardrail) - [Deterministic containment](https://aisdlc.ai/agentic-engineering/deterministic-containment) - [Eval-driven development](https://aisdlc.ai/agentic-engineering/eval-driven-development) - [Human accountability](https://aisdlc.ai/agentic-engineering/human-accountability) **Connected Insights** - [Verification is a plane, not a phase](https://aisdlc.ai/insights/verification-is-a-plane-not-a-phase) ## 07 · Close the evidence and lifecycle loop **Driving question:** When an agent's output is questioned a year later, what record answers the question without asking the people who were there? Design one addressable record that links runs, findings, approvals, releases, incidents, recertification, and retirement. ### Learning objectives - Give every run, finding, and decision a stable identifier that later records can reference. - Attach provenance to a release so the exact candidate, verifier, and approver stay recoverable. - Reopen standing when an incident, drift signal, or recertification date arrives. - Define retirement so a decommissioned agent's record remains readable. ### Study sequence 1. **[What a record must carry](/agentic-engineering/evidence-engineering)** — read, 16 min. Define the record before the run, not after the context is gone. 2. **[Telemetry volume against decision evidence](/insights/evidence-before-autonomy)** — compare, 18 min. Separate the stream nobody reads from the records a decision rests on. 3. **[Trace one release back to its intent](/agent-estate)** — practice, 30 min. Walk the spine backwards until a link breaks. ### Field exercise Build the evidence spine for one released agent change and walk it backwards from the release to the original intent. **Deliverable:** An evidence spine with identifiers, named approvals, recertification triggers, and retirement handling. **Independent challenge:** A reviewer picks any released change and reconstructs its intent, verifier findings, and named approver without contacting the people who built it. **Evidence to retain** - Evidence spine map - Identifier scheme - Named approval record - Recertification trigger list - Retirement and retention rule **Connected knowledge** - [Evidence engineering](https://aisdlc.ai/agentic-engineering/evidence-engineering) - [Continuous recertification & retirement](https://aisdlc.ai/agentic-engineering/continuous-recertification-retirement) - [Agent incident response](https://aisdlc.ai/agentic-engineering/agent-incident-response) - [Agent estate governance](https://aisdlc.ai/agentic-engineering/agent-estate-governance) - [Observability](https://aisdlc.ai/agentic-engineering/observability) - [Human accountability](https://aisdlc.ai/agentic-engineering/human-accountability) **Connected Insights** - [Evidence before autonomy](https://aisdlc.ai/insights/evidence-before-autonomy) ## Capstone · Agent platform service dossier Carry one real agent workload across every platform service in this path, from substrate and identity through context, tools, orchestration, verification, and evidence, and close it with a named human disposition rather than an agent decision. ### Deliverables - Substrate contract with isolation boundaries, credential handling, and recovery procedure - Identity record naming purpose, sponsor, accountable owner, scoped permissions, and expiry - Context manifest with source versions, trust classes, and retention rules - Typed tool contract set separating inspect, propose, execute, and commit capability - Run ledger with budgets, handoff contracts, and a finite terminal disposition list - Verifier plane map with owners, triggers, block authority, and escalation paths - Evidence spine linking the run to findings, approval, recertification trigger, and retirement handling ### Verification - A reviewer who did not build the dossier traces one run from intent to disposition using only the written artifacts - Every service in the slice names an owner who is neither the agent nor the person who designed it - An out-of-scope action is refused by a written contract rather than by model cooperation - Unresolved gaps, residual exposure, and untested assumptions remain visible instead of being resolved on paper - The final disposition on the slice is recorded by a named human, not by the learner's agent Progress and completion are self-directed learning records. They are not certification, professional standing, production evidence, or authorization to deploy an agentic system. ## Boundaries This curriculum is original AISDLC editorial synthesis informed by cited research, official documentation, standards, open-source references, and attributed practitioner perspectives. It is learning material—not a standard, production approval, compliance determination, or proof that a depicted control is implemented. Progress and completion are self-directed learning records. They are not certification, professional standing, production evidence, or authorization to deploy an agentic system.