Morty Taghdisi

Series

Agentic Engineering

A series on building AI-assisted delivery systems that stay coherent: governed agents, shared product memory, and delivery workflows that reduce drift across teams and platforms.

Reading order

  1. 01AI Agents Need Architectural Boundaries, Not Just PromptsAgentic systems fail the same way early microservices did: teams optimize for capability before they define clear architectural boundaries.
  2. 02LLM Wiki for Software Teams: Two Problems AI Agents Can't Fix ThemselvesMost multi-platform teams use AI agents as isolated workers with no shared memory. This creates two distinct failure modes: inconsistent implementations and domain blindness. They need two different fixes.
  3. 03Keeping Spring Boot Delivery Aligned with Product Context and Engineering StandardsBackend delivery loses alignment by the third feature when agents work from generic prompts with no shared context. Focused skill decomposition, wiki-driven product context, and explicit delivery commands keep a Spring Boot repo consistent over time.
  4. 04AI Agents in the SDLC: What Changes Beyond Code GenerationOne made-up research desk, one memo that reached clients unsigned. A risk-tier matrix, an intent record with owners, a single publishing service with tests, the permissions the agent never gets, and what changes when several agents argue.
  5. 05What a Passing Test or Eval Tells You About an Agent-Written ChangeTests check what someone encoded, evals sample what an agent does. A Python eval package for a coding agent and a debate agent, critical checks that always block, a protected CI gate, and what five green runs really prove.
  6. 06Agents Can Open the Pull Request, but They Cannot Sign the ReleaseTwo reviews, one software signature, a separate memo approval, and an agent identity that cannot approve its own work. A RACI, branch policies, a requester check, a release record bound to the artifact, and a one-page card for the approver.
  7. 07How to Tell Whether the Agent Workflow Improved DeliveryOutput counts measure adoption, not delivery. A dashboard contract that separates delivery tiles from publication-control tiles, Python for the one rate worth starting with and for valid sign-off at publication time, and an audit record for every agent run.
  8. 08Agent-Written Prose Has No Failing TestA memo claim pointed at a real, sourced note and still said more than the note did. Every check passed. A numeric reproducer, a rubric, a claim ledger and an independent reader for the claims that have no reproducer.

The four questions, and a fifth

Parts 7 to 10 follow the four questions I ask every time work moves from one stage to the next. Part 11 asks the question the other four leave open.

  1. What may the agent do here? Risk tiers, written intent, one publishing path and the permissions the agent never gets: AI Agents in the SDLC.
  2. What artifact stays behind when this step is done? Tests, eval cases for the coding agent and the skeptic, and the evidence they leave: What a Passing Test or Eval Tells You.
  3. Who decides whether the work moves on? Two reviews, one software signature, a separate memo approval, and an agent that cannot approve: Agents Cannot Sign the Release.
  4. What evidence has to exist before it may? A dashboard contract, valid sign-off at publication time, and a record of every agent run: How to Tell Whether the Agent Workflow Improved Delivery.
  5. What checks the claims? Traceability is not truth: a reproducer, a claim ledger and an independent reader: Agent-Written Prose Has No Failing Test.

The running example

These parts share one illustrative story. A research desk app lets AI agents research a question, argue it out (an advocate, a skeptic and a moderator) and write a memo. A researcher makes the final call and approves the memo for clients. A small team builds the app with a coding agent.

The product manager asks for one-click publishing of memos to clients. The coding agent ships an endpoint that skips a rule the ticket never mentions: every claim in a published memo traces to a sourced note, and a named researcher signs off the exact memo before it reaches clients. The rule existed elsewhere in the repo, in the policy the old export used, but it was missing from the ticket and from the new endpoint's checks. Memo M-104 goes out unsigned, with two untraced claims and one claim that says more than its note.

Each part looks at that failure as it happened, before the controls, and adds one more safeguard. The code in every part uses the same memo, notes and claim ids.