AI-DLC Fixed the Process. The Knowledge Is Still Local.

In January I wrote that spec-driven tools are a local optimization trap. OpenSpec and GitHub Spec Kit are great for one developer or one greenfield repo, but they don’t compound organizational knowledge. In LEAN terms, that’s sub-optimization waste.

AWS has since shipped the most serious answer to that critique I’ve seen: AI-DLC, the AI-Driven Development Life Cycle. It is not a spec template. It is a real engine, and it deserves a real look.

Here’s my take after reading the code and the docs. AI-DLC fixed the process side of local optimization. The knowledge side is still local. The trap didn’t go away. It moved down a layer.

What AI-DLC Gets Right

The original AWS blog post read like a methodology deck: Inception, Construction, Operations, mob rituals, bolts instead of sprints. The awslabs/aidlc-workflows repo is something else. It turns that methodology into a working system:

• A deterministic engine. An engine decides the next stage; the agent session executes it. Routing isn’t left to the model’s mood.
• Real structure. 5 phases, 33 stages, 14 agents, and workflow profiles for features, bug fixes, infrastructure, security, and POCs.
• Governance built in. Human approval gates after every stage, an audit trail of every decision, and persistent state across sessions.
• A rule chain. Behavioral rules resolve from org to team to project to phase to stage, and a learning loop captures new rules as teams work.
• Brownfield support. A reverse engineering stage builds an understanding of existing code before anything changes.
• Harness neutral. One core runs natively in Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, and GitHub Copilot.

This is a serious answer to “how should an AI agent move through a delivery lifecycle?” If your developers are using coding agents with no structure at all, AI-DLC is a big step up. I’d recommend it.

Where the Trap Moved

Every stage in AI-DLC loads its context the same way: rules, methodology, team knowledge, then prior artifacts. Look at where team knowledge comes from. I don’t need to characterize it, because the AI-DLC knowledge guide is admirably honest about it:

• It starts empty. The team knowledge folder is created empty on first run. Every standard, pattern, and policy is a markdown file someone writes by hand.
• It loads whole. There’s no retrieval. Files are injected into context as they are, and the guide warns that stale or contradictory files confuse agents because they carry equal weight.
• It ages manually. The recommended fix for drift is a scheduled prune: open each file, check it still reflects reality, update or delete it.
• It lives in one repo. Knowledge, the code knowledge base, and memory all sit under a space inside that repository.
• Documents need to be dropped in. The document catalog indexes PDFs, Word files, and specs, but only after someone copies them into a folder and onboards them.

None of that is a criticism of the engineering. It’s the natural limit of a framework that runs inside a developer’s session. But read it again with an enterprise in mind:

• The architect agent designs a change without knowing who calls the code in any other repo the organization owns.
• Three teams each run AI-DLC, and each writes its own auth standard into its own knowledge folder.
• The Confluence page says one thing, the code does another, and both get loaded with equal weight.
• The engineer who knew why that legacy module works the way it does has left, and nobody wrote it down.

That’s the same list from January. The process is now systemic. The knowledge is still repo-bound. AI-DLC answers how the agent should work. It can’t answer what the organization already knows.

It’s Not Just a Bigger Pile of Markdown Files

The instinct here is to fix AI-DLC’s knowledge folder by filling it in better: more files, better organized, reviewed on a stricter cadence. That helps, but it doesn’t close the gap, because the gap isn’t a content problem. I wrote a longer answer to what does a good organizational intelligence layer actually look like, built around five pillars. Two of them are exactly what a folder of markdown files, no matter how well maintained, structurally cannot become.

Code wins over docs. AI-DLC’s own knowledge guide says the quiet part out loud: stale or contradictory files confuse agents because they’re loaded literally, with equal weight, every time. A markdown file has no way to know it’s wrong. It just sits in the folder until someone notices on the next quarterly prune. An intelligence layer anchors every answer to the code as it exists right now. Code and documentation retrieve through separate channels, reranked independently and merged for synthesis, specifically so a stale document can’t outrank or drown out what the code actually does.

It’s retrieved, not injected whole. Every AI-DLC stage loads its knowledge files whole: the shared folder, plus the active agent’s own folder, relevant or not. An intelligence layer retrieves the slice that actually answers the question (a runbook and a deploy log, a code-map and an ADR), not the whole corpus dumped in on the chance something in it is useful.

There’s a third piece that post didn’t cover, because it’s less about knowledge management than about structure: a symbol graph. This is a deterministic structural index, extracted alongside the code maps and kept separate from vector search: callers(), importers(), implementers(), definitions(), queried in parallel with retrieval and shown in the UI as its own routing path so you can tell at a glance whether an answer is graph-grounded (deterministic: the table says X calls Y) or vector-grounded (probabilistic: the chunk that matched contained text about Y). When there are no callers, it says so instead of guessing. That’s not a markdown file anyone could write by hand. “Who calls this function across every repo in the workspace” isn’t a fact you document. It’s a fact you compute.

That’s the architect-agent bullet from the list above, concretely. AI-DLC’s architect doesn’t see outside its own repo. OutcomeOps answers callers() across every repo in the workspace being queried.

Kiro Can Use It Too

I don’t use Kiro day to day, so I didn’t run a full AI-DLC workflow through it stage by stage. What I tested is narrower and, for this argument, more important: whether Kiro can talk to the OutcomeOps MCP server at all. It can: the same protocol, the same tools (query_knowledge_base, callers, importers, read_source), the same results Claude Code gets. No Kiro-specific adapter, no special-casing.

That matters because AI-DLC is explicitly harness neutral: one core, running in Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, and GitHub Copilot. The org-level rule below isn’t Kiro-specific either. Point it at whichever harness is actually running AI-DLC’s stages for a given team, and the knowledge gap closes the same way regardless of which IDE that team prefers.

Wiring It Up

No fork, no plugin build. Two steps:

1. Connect the MCP server. Add OutcomeOps as an MCP server in your harness (Kiro, Claude Code, Cursor, or any client AI-DLC supports) using an API key or your Entra ID token. The agent now sees every workspace you have access to.
2. Add one org-level rule. Put it in AI-DLC’s rule chain so every stage inherits it:

Before making assumptions about existing code, dependencies, standards,
or requirements, query the OutcomeOps MCP server:
- query_knowledge_base for ADRs, standards, and related docs
- callers, importers, implementers, definitions for structural questions
- read_source to verify any file citation at its commit

Cite what you find. If OutcomeOps returns no callers, say so.

That’s it. AI-DLC still owns the workflow, the gates, and the audit trail. OutcomeOps supplies the context those stages run on.

Better Together, Again

I said the same thing about Kiro and OutcomeOps, and it holds here. AI-DLC and OutcomeOps aren’t competing for the same layer:

• AI-DLC decides how an agent moves through the lifecycle: stages, gates, rules, audit.
• OutcomeOps decides what the agent knows: code maps, symbol graphs, ADRs, and every system your org already writes things down in.

Run AI-DLC on its own and every team gets a better process sitting on its own island of knowledge. Run it with OutcomeOps and the process sits on everything the organization already knows. That’s the difference between local optimization and systemic acceleration.

If you’re rolling out AI-DLC across more than a handful of teams, book an enterprise briefing and I’ll run AI-DLC against your own repos, with and without OutcomeOps wired in, live.

Related reading

• Spec-Driven Tools Are Local Optimization — the January post this one is the follow-up to.
• AWS Kiro + OutcomeOps — the same MCP pattern, connected to Kiro directly rather than through AI-DLC.
• What a Good Organizational Intelligence Layer Looks Like — the five pillars AI-DLC’s knowledge folder can’t become on its own.