Engineering with agents without losing engineering

01 · Field module

See the whole system

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 · read · 15 min

   Establish the system vocabulary before discussing implementation technique.

2. The model is not the architecture · read · 12 min

   Separate rented capability from the engineered system around it.

3. Practitioner lens: fundamentals under acceleration · 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

02 · Field module

Align before implementation

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 · read · 14 min

   Define what durable intent must carry into execution and review.

2. Practitioner lens: idea to implementation workflow · watch · 18 min

   Study one practitioner flow while keeping its claims and enterprise extensions explicit.

3. Compare specification roles · 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

03 · Field module

Shape an agent-readable codebase

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 · read · 15 min

   Connect codebase shape to the tools and feedback surfaces around agent work.

2. Practitioner lens: deliberate module depth · 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 · 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

04 · Field module

Slice for fast feedback

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 · watch · 16 min

   Separate decision mapping from downstream specifications and implementation tickets.

2. Own the speed · read · 14 min

   Connect local generation speed to review, integration, verification, and decision capacity.

3. Write one tracer-slice plan · 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

05 · Field module

Build against evidence

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 · read · 16 min

   Place acceptance and failure hypotheses before implementation.

2. Practitioner lens: tests and fast feedback · watch · 19 min

   Assess test-driven practice as a construction loop rather than a complete assurance claim.

3. Compare deterministic and model-based checks · 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

06 · Field module

Verify independently

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 · read · 15 min

   Apply challenge across intent, build, release, and operation.

2. Fresh context versus independent challenge · compare · 18 min

   Preserve the value of a fresh review while locating the stronger enterprise independence boundary.

3. Design a blocking verifier · 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

07 · Field module

Scale without losing control

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 · read · 15 min

   Model the rate at which generated work becomes understood, verified, integrated, authorized, and operated value.

2. Factory or queue amplifier? · compare · 20 min

   Separate repeatable production systems from uncontrolled artifact generation.

3. Rehearse a hold, correction, and release · 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

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.

Other published paths

• Private AI and owned inference
• Agent platform engineering
• Lead AI-native delivery