# Engineering with agents without losing engineering

**Agentic Engineering Field Curriculum · Edition 2026.08 · Reviewed 2026-08-10**

Move from model-assisted coding to a bounded, inspectable, independently challenged delivery system.

Level: practitioner · Designed for Engineer, Architect, Platform · Estimated study: 9 hours · 7 finite stages

Canonical page: https://aisdlc.ai/agentic-engineering/learn/agentic-engineer-core

## 01 · See the whole system

**Driving question:** What exists around the model before software can behave as an accountable agentic system?

Describe an agent as a bounded system of model, loop, context, tools, harness, substrate, identity, verification, and human authority.

### Learning objectives

- Distinguish a model, workflow, agent, harness, and execution substrate.
- Trace where state, tools, permissions, and exit conditions enter an agent loop.
- Identify which layers guide behavior and which layers can enforce a boundary.

### Study sequence

1. **[Anatomy of an AI agent](/agentic-engineering/ai-agent)** — read, 15 min. Establish the system vocabulary before discussing implementation technique.
2. **[The model is not the architecture](/insights/the-model-is-not-the-architecture)** — read, 12 min. Separate rented capability from the engineered system around it.
3. **[Practitioner lens: fundamentals under acceleration](https://www.youtube.com/watch?v=v4F1gFy-hqg)** — watch, 19 min. Compare the practitioner argument with the AISDLC system and authority boundaries.

### Field exercise

Draw the smallest complete agentic system for one real task and mark every state, action, trust, and decision boundary.

**Deliverable:** An annotated system anatomy with explicit boundaries and unresolved assumptions.

**Independent challenge:** A reviewer must be able to locate the model, harness, substrate, tools, identity, verifier, evidence sink, and human authority without oral explanation.

**Evidence to retain**

- System anatomy
- Boundary legend
- Assumption register

**Connected knowledge**

- [AI agent](https://aisdlc.ai/agentic-engineering/ai-agent)
- [Agentic engineering](https://aisdlc.ai/agentic-engineering/agentic-engineering)
- [Agent loop](https://aisdlc.ai/agentic-engineering/agent-loop)
- [Harness engineering](https://aisdlc.ai/agentic-engineering/harness-engineering)
- [Agent execution substrate](https://aisdlc.ai/agentic-engineering/execution-substrate)

**Connected Insights**

- [The model is not the architecture](https://aisdlc.ai/insights/the-model-is-not-the-architecture)

## 02 · Align before implementation

**Driving question:** How do people and agents reach enough shared understanding to build the right thing?

Turn an ambiguous request into durable intent, explicit decisions, acceptance signals, and a bounded specification without treating the specification as a substitute for code comprehension.

### Learning objectives

- Separate facts an agent can research from decisions an accountable person must make.
- Choose conversation, research, or prototype according to the fidelity needed to resolve a question.
- Write intent that carries measurable acceptance, constraints, ownership, and known unknowns.

### Study sequence

1. **[Intent as an engineering artifact](/agentic-engineering/intent-engineering)** — read, 14 min. Define what durable intent must carry into execution and review.
2. **[Practitioner lens: idea to implementation workflow](https://www.youtube.com/watch?v=M6mYodf0dJM)** — watch, 18 min. Study one practitioner flow while keeping its claims and enterprise extensions explicit.
3. **[Compare specification roles](/agentic-engineering/intent-engineering)** — compare, 20 min. Distinguish spec-first, spec-anchored, spec-as-source, and naive one-shot spec-to-code behavior.

### Field exercise

Interrogate one feature request until its decisions, unknowns, acceptance signals, and authority are explicit.

**Deliverable:** An intent brief with decision log, acceptance contract, unresolved questions, and named owner.

**Independent challenge:** A separate reviewer challenges whether every acceptance statement is observable and every consequential decision has a human owner.

**Evidence to retain**

- Intent brief
- Decision log
- Acceptance contract
- Open-question register

**Connected knowledge**

- [Intent engineering](https://aisdlc.ai/agentic-engineering/intent-engineering)
- [Context engineering](https://aisdlc.ai/agentic-engineering/context-engineering)
- [Working state](https://aisdlc.ai/agentic-engineering/working-state)
- [Goal and exit condition](https://aisdlc.ai/agentic-engineering/goal-exit-condition)

**Connected Insights**

- [Context is a runtime system](https://aisdlc.ai/insights/context-is-a-runtime-system)

## 03 · Shape an agent-readable codebase

**Driving question:** What architecture lets humans retain strategic understanding while agents execute more tactical work?

Design stable seams, compact interfaces, local feedback, and durable repository context that both humans and agents can navigate.

### Learning objectives

- Identify shallow dependency webs that increase context and test cost.
- Design substantial behavior behind a small, explicit interface.
- Preserve a human-readable module map and source-of-truth boundaries.

### Study sequence

1. **[Harness engineering as platform engineering](/insights/harness-engineering-is-platform-engineering)** — read, 15 min. Connect codebase shape to the tools and feedback surfaces around agent work.
2. **[Practitioner lens: deliberate module depth](https://www.youtube.com/watch?v=v4F1gFy-hqg)** — watch, 19 min. Study the deep-module interpretation without copying the source diagram or treating it as a universal architecture.
3. **[Map interfaces before implementation](/agentic-engineering/harness-engineering)** — practice, 30 min. Make architectural strategy inspectable before tactical generation begins.

### Field exercise

Choose one dependency-heavy area and redesign its boundary on paper before changing code.

**Deliverable:** A before-and-after module map with interface contract and test seam.

**Independent challenge:** A reviewer must be able to explain the new boundary and its failure containment without reading every implementation file.

**Evidence to retain**

- Dependency map
- Interface contract
- Test-seam proposal
- Tradeoff note

**Connected knowledge**

- [Harness engineering](https://aisdlc.ai/agentic-engineering/harness-engineering)
- [Working state](https://aisdlc.ai/agentic-engineering/working-state)
- [Durable project memory](https://aisdlc.ai/agentic-engineering/durable-memory)
- [Instruction–data trust boundary](https://aisdlc.ai/agentic-engineering/instruction-data-trust-boundary)

**Connected Insights**

- [Harness engineering is platform engineering](https://aisdlc.ai/insights/harness-engineering-is-platform-engineering)

## 04 · Slice for fast feedback

**Driving question:** How should work be divided so each agent session produces an inspectable end-to-end result?

Turn a durable destination into vertically sliced, dependency-aware work that fits bounded contexts and exposes feedback early.

### Learning objectives

- Distinguish decision work from implementation work.
- Prefer end-to-end tracer slices over horizontal layer batches.
- Use dependencies, work-in-process limits, and phase boundaries to control concurrency.

### Study sequence

1. **[Practitioner lens: map the fog before building](https://www.youtube.com/watch?v=F3lL98Pj90o)** — watch, 16 min. Separate decision mapping from downstream specifications and implementation tickets.
2. **[Own the speed](/insights/own-the-speed)** — read, 14 min. Connect local generation speed to review, integration, verification, and decision capacity.
3. **[Write one tracer-slice plan](/enterprise-aisdlc)** — practice, 35 min. Create a small end-to-end path with an external acceptance signal.

### Field exercise

Decompose the aligned feature into end-to-end slices with explicit blocking edges and feedback.

**Deliverable:** A tracer-slice map with acceptance and blocking relationships.

**Independent challenge:** A reviewer rejects any slice that is only a database, API, UI, or documentation layer without an independently observable outcome.

**Evidence to retain**

- Slice map
- Blocking graph
- Acceptance path
- Work-in-process rule

**Connected knowledge**

- [Goal and exit condition](https://aisdlc.ai/agentic-engineering/goal-exit-condition)
- [Working state](https://aisdlc.ai/agentic-engineering/working-state)
- [Durable execution](https://aisdlc.ai/agentic-engineering/durable-execution)
- [Organizational absorption capacity](https://aisdlc.ai/agentic-engineering/organizational-absorption-capacity)

**Connected Insights**

- [Own the speed](https://aisdlc.ai/insights/own-the-speed)

## 05 · Build against evidence

**Driving question:** What feedback must exist before an agent begins changing the system?

Design deterministic tests, evaluations, typed outputs, and outcome checks that let construction advance in small verified increments.

### Learning objectives

- Translate acceptance statements into externally observable checks.
- Use red-green-refactor and fast feedback where the task permits it.
- Separate implementation self-checks from release-grade independent verification.

### Study sequence

1. **[Eval-driven development](/agentic-engineering/eval-driven-development)** — read, 16 min. Place acceptance and failure hypotheses before implementation.
2. **[Practitioner lens: tests and fast feedback](https://www.youtube.com/watch?v=v4F1gFy-hqg)** — watch, 19 min. Assess test-driven practice as a construction loop rather than a complete assurance claim.
3. **[Compare deterministic and model-based checks](/agentic-engineering/llm-as-judge)** — compare, 24 min. Choose an oracle according to the failure hypothesis and its own known limitations.

### Field exercise

Write the acceptance and regression checks for one tracer slice before producing its implementation.

**Deliverable:** A runnable verification contract and empty evidence manifest.

**Independent challenge:** An independent reviewer challenges whether the checks would detect a plausible wrong implementation, not merely confirm execution.

**Evidence to retain**

- Failing baseline
- Verification contract
- Evaluator manifest
- Expected evidence schema

**Connected knowledge**

- [Eval-driven development](https://aisdlc.ai/agentic-engineering/eval-driven-development)
- [Structured output](https://aisdlc.ai/agentic-engineering/structured-output)
- [LLM as judge](https://aisdlc.ai/agentic-engineering/llm-as-judge)
- [Observability](https://aisdlc.ai/agentic-engineering/observability)

**Connected Insights**

- [Verification is a plane, not a phase](https://aisdlc.ai/insights/verification-is-a-plane-not-a-phase)

## 06 · Verify independently

**Driving question:** Who or what can credibly challenge the builder before a consequential result advances?

Design an independent verifier with named ownership, trigger, scope, block authority, method, and recorded disposition.

### Learning objectives

- Distinguish fresh-context self-review from zero-trust independent verification.
- Combine algorithmic and agentic checks rather than choosing one exclusively.
- Escalate disagreement to named human authority instead of averaging it away.

### Study sequence

1. **[Verification is a plane, not a phase](/insights/verification-is-a-plane-not-a-phase)** — read, 15 min. Apply challenge across intent, build, release, and operation.
2. **[Fresh context versus independent challenge](https://www.youtube.com/watch?v=v4F1gFy-hqg)** — compare, 18 min. Preserve the value of a fresh review while locating the stronger enterprise independence boundary.
3. **[Design a blocking verifier](/assurance-case)** — practice, 35 min. Make ownership, block semantics, and evidence inspectable.

### Field exercise

Specify one named verifier for the tracer slice and run it against a deliberately flawed candidate.

**Deliverable:** A verifier contract, challenged candidate, finding, and disposition record.

**Independent challenge:** A human assurance owner confirms that the check has a defined trigger, scope, authority to block, and recorded disposition.

**Evidence to retain**

- Verifier identity and version
- Challenge input
- Finding
- Block or pass decision
- Disposition

**Connected knowledge**

- [Independent verifier systems](https://aisdlc.ai/agentic-engineering/multi-agent-verification)
- [Human accountability](https://aisdlc.ai/agentic-engineering/human-accountability)
- [Evidence engineering](https://aisdlc.ai/agentic-engineering/evidence-engineering)
- [Deterministic containment](https://aisdlc.ai/agentic-engineering/deterministic-containment)

**Connected Insights**

- [Verification is a plane, not a phase](https://aisdlc.ai/insights/verification-is-a-plane-not-a-phase)
- [Evidence before autonomy](https://aisdlc.ai/insights/evidence-before-autonomy)

## 07 · Scale without losing control

**Driving question:** How does an organization absorb more agent output without surrendering quality, accountability, or comprehension?

Balance generation with product decisions, verifier capacity, integration, evidence, runtime intervention, and named human release authority.

### Learning objectives

- Diagnose the value-stream constraint instead of treating pull-request volume as delivered value.
- Scale verifier and integration capacity with generation capacity.
- Connect release evidence to runtime monitoring, intervention, recertification, and retirement.

### Study sequence

1. **[Organizational absorption capacity](/agentic-engineering/organizational-absorption-capacity)** — read, 15 min. Model the rate at which generated work becomes understood, verified, integrated, authorized, and operated value.
2. **[Factory or queue amplifier?](/agentic-engineering/software-factory)** — compare, 20 min. Separate repeatable production systems from uncontrolled artifact generation.
3. **[Rehearse a hold, correction, and release](/control-plane-lab)** — practice, 35 min. Practice finite intervention verbs while preserving the simulation boundary.

### Field exercise

Map one delivery value stream and redesign it for higher verified throughput rather than higher artifact volume.

**Deliverable:** A current-state and target-state absorption map with operating limits.

**Independent challenge:** Engineering, assurance, and product owners each identify their queue, decision right, evidence need, and stop condition.

**Evidence to retain**

- Value-stream map
- Capacity assumptions
- Work-in-process limits
- Authority map
- Runtime stop conditions

**Connected knowledge**

- [Agentic software factory](https://aisdlc.ai/agentic-engineering/software-factory)
- [Organizational absorption capacity](https://aisdlc.ai/agentic-engineering/organizational-absorption-capacity)
- [Runtime policy enforcement](https://aisdlc.ai/agentic-engineering/runtime-policy-enforcement)
- [Agent incident response](https://aisdlc.ai/agentic-engineering/agent-incident-response)
- [Continuous recertification & retirement](https://aisdlc.ai/agentic-engineering/continuous-recertification-retirement)

**Connected Insights**

- [Own the speed](https://aisdlc.ai/insights/own-the-speed)
- [Evidence before autonomy](https://aisdlc.ai/insights/evidence-before-autonomy)

## Capstone · Bounded feature evidence dossier

Carry one reversible feature from clarified intent through an end-to-end slice, bounded agent implementation, independent challenge, evidence packaging, and a named human release disposition.

### Deliverables

- Intent and decision record
- System and module maps
- Tracer-slice plan
- Test and evaluation receipts
- Independent verifier disposition
- Human release decision and rollback condition

### Verification

- Every artifact names the exact candidate it describes
- The verifier is independent of the builder
- Known limitations and unresolved findings remain visible
- The release decision is human, named, and reversible

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.
