In the last year, a strong set of frameworks has emerged to structure how AI agents execute the software development lifecycle. Different vendors, different philosophies, different acronyms: AI-DLC (AI-Driven Development Life Cycle), ADLC (Agentic Development Life Cycle), A-SDLC (Agentic SDLC), ASD (Agentic Software Development), and SDD (Spec-Driven Development), which is often used loosely to mean the same thing. All these acronyms focus on AI executing the process: agents doing the actual dev work (writing specs, code, tests) with humans governing checkpoints. It's worth distinguishing that definition from how the term tends to get used day to day. In most organizations, "AI-DLC" in practice describes something narrower: the same roles and review structure as before, with AI assisting at each step to go faster, rather than the labor itself being restructured. That's not a shortcoming of any framework; it's a familiar pattern with any process change. A methodology can define a genuine restructuring, and an organization can still adopt only the parts that fit smoothly into what it already does, leaving the deeper change on the table, and a framework can look structural on paper while still getting used as a speed hack because nothing forces the restructuring to happen. That gap between what's defined and what typically gets adopted is likely a big part of why adoption keeps climbing while outcomes barely move.
Two distinct tiers have emerged in this space. The first is enterprise lifecycle models, which offer broad, phase-based methodologies that govern the entire dev lifecycle end-to-end, typically with mandatory human checkpoints and audit trails built in. Some function purely as a governance layer over whatever workflow you already run rather than a build methodology in their own right. The second is spec-driven development (SDD) toolkits, a more concrete, mostly open-source category where a written specification becomes the shared source of truth that agents plan and implement from, ranging from heavyweight simulated-team approaches to deliberately lightweight ones. Across both tiers, the tools trade off the same handful of properties differently, weighing process depth, portability across agents, and vendor lock-in in different ways. Each of these frameworks offers something genuinely useful, but each also breaks in a specific, and often shared way.
Eight problems, one root cause
As with any emerging space, trade-offs are inevitable: more structure often means more complexity, faster iteration often means lighter validation, and newer approaches simply need time to build up proof and adoption. Different frameworks land in different places on these trade-offs, but looking across them, eight common themes stand out:
- Missing traceability across tools, where nothing ties spec version, code version, and decision history together over time, so a spec, the agent context behind it, the resulting code, and the incident it later caused all end up living in separate systems with no link between them. Spec/code drift is just the visible symptom of that missing link.
- A trade-off between depth and portability, where frameworks with real process depth tend to sacrifice portability, while the portable ones sacrifice roles and validation.
- Security bolted on separately, where governance lives outside the methodology rather than inside it.
- Duplicated context work, where every team ends up independently reinventing the same grounding work, such as architectural decisions, service ownership, and domain constraints, inside its own repo.
- Unmeasured claims, where most of the productivity numbers in circulation come from vendor case studies rather than the organization's own measurement.
- Weak operations and post-deploy coverage, where almost every framework goes thin or falls silent once code ships.
- Supply-chain risk, where community skills, templates, and extensions are largely unvetted, and their maintainers can disappear or move on without warning.
- No native brownfield path, where nearly all of them assume greenfield development, treating legacy-system recovery as a rare exception rather than the norm.
Each of the eight problems above can be read as a symptom of the same underlying gap: spec, context, code, tests, decisions, and security checks are tracked as disconnected artifacts, with no shared layer connecting them. The opportunity isn't another framework; it's the infrastructure layer connecting the ones that already exist, which is exactly the kind of problem platform engineering already exists to solve.
How platform engineering fills the gap
The eight problems above are distinct on the surface, but the fixes share a common shape: some piece of context, a decision, a check, a record of what happened, exists somewhere, but nowhere the rest of the system can see or act on it. The fix is always the same move applied to a different layer: take something that lives locally, per team, per repo, or per tool, and make it a shared, searchable capability the platform owns, and every team draws from by default. The provenance ledger anchors this for traceability; golden paths apply it to process depth; guardrails apply it to security; the knowledge service applies it to context; telemetry applies it to measurement; the living-spec loop applies it to operations; the registry applies it to trust; the legacy golden path applies it to brownfield work. A shared gate engine applies the same logic to enforcement itself, turning approvals and checks into binding rules instead of optional suggestions. What follows works through that move for each problem.
Fixing missing traceability with a shared provenance ledger
The problem isn't that any single system fails to track its own history; it's that nothing links those histories together. An agent's context, the spec version it worked from, the guardrail checks it triggered, and the incident that later exposed a gap all live in separate tools with no thread connecting them. "Drift," the spec and code quietly disagreeing, is just the visible symptom. No single tool can fix this, since each only sees what it owns: code, maybe spec files, never an agent's context snapshot or an incident happening elsewhere.
The fix is a shared provenance ledger, hosted on the IDP, that ingests events from source control, the coding agent, guardrails, and observability, linking them by a common reference like commit SHA or spec version. Source control stays the system of record for content; the ledger just connects versions and decisions across tools into one traceable chain. The IDP is the natural home for it: it already aggregates systems vendor-neutrally and operates with org-wide authority across repos and teams, exactly the reach a cross-tool ledger needs. The payoff: drift becomes a searchable gap, surfaced the moment an artifact shows up without a matching entry elsewhere in the chain.
Fixing the depth-vs-portability trade-off with golden paths
Depth and portability look like a trade-off, but the real cause is simpler: process rigor and agent execution are welded into one artifact instead of kept as separate layers. Deep frameworks hardcode rigor into scripts tied to one agent; portable ones strip that rigor out to stay generic. Either way, teams choose between real depth locked to a vendor, or portability with almost no structure underneath it.
The fix is golden paths: the platform defines process depth, roles, approvals, phase gates, once as a portable, agent-agnostic manifest, with a thin adapter translating it to whatever agent a team runs. This is platform work, not a single team's, since defining reusable defaults is the platform's job, and the value only appears when one manifest is reused across teams rather than each writing its own. The forced choice disappears: a team inherits real depth and cross-agent portability from day one, and when the agent landscape shifts, the platform absorbs that change once instead of every team absorbing it separately. A policy-as-code gate engine enforces this by blocking a merge until required approvals are logged, turning "required approvals" from a line in a document into something a change can't skip.
Fixing bolted-on security with guardrails as shared pipeline middleware
The problem is that security for agentic development tends to arrive as an afterthought: a separate tool bolted onto whatever workflow a team already has running rather than built into it. The ordering matters. An external guardrail layer inspects prompts, file access, and tool calls after the workflow is already designed without them in mind, and it keeps its own log of what it caught and blocked. The result is two parallel records that both claim to describe what happened during development, the delivery pipeline's and the security tool's, with nothing tying them together and no guarantee they agree.
The fix is guardrails as shared pipeline middleware: real-time screening of prompts, file reads, and tool calls becomes a platform service every pipeline calls as a normal part of execution, not a layer added afterward. This only works if one layer owns it consistently across teams, since policy meant to apply org-wide needs enforcement with that same reach, not a tool individual teams can opt into or skip. Its events write to the same ledger as every other artifact, so a blocked prompt becomes just another entry alongside the commit and test result, enforced through the same gate engine that makes approvals binding, so security shows up exactly where a reviewer is already looking instead of a system to cross-reference after the fact.
Fixing duplicated context work with a shared knowledge service
Every team working with agents ends up solving the same context problem independently: before an agent can act correctly, it needs architectural decisions, service ownership, and domain constraints, none of which live anywhere it can query directly. Instead they're scattered across design docs, tribal knowledge, and whatever an engineer pastes into a prompt that day. Each team rebuilds that grounding from scratch, with no guarantee two teams on adjacent services share the same understanding of the architecture.
The fix is a platform-owned context and knowledge service: architectural decisions, ownership, and constraints get indexed once, centrally, as a layer agents query directly instead of relying on whatever a person manually assembles. This is platform work by nature, since those decisions span multiple teams already and need the same cross-team reach the platform has. A single team indexing its own context solves nothing beyond itself. Context stops being reinvented per repo: every agent draws from the same ground truth, and when it changes, it's updated once instead of chased down across every prompt it was ever pasted into.
Fixing unmeasured claims with DORA-style telemetry
Almost every claim about agentic development's impact, productivity gains, time saved, quality, comes from the vendor selling the framework, not independent measurement inside the org using it. That's not necessarily dishonest, but it leaves an org unable to verify whether the approach works under its own codebase and constraints. Organizations are not necessarily tracking drift frequency, gate bypasses, or how many corrections an agent's output needs before it's mergeable. That data gap means assessments of process effectiveness are generally based on anecdote or vendor-reported numbers rather than an org's own measurements.
The fix is observability and DORA (DevOps Research and Assessment)-style telemetry: since every artifact already flows through the shared ledger, many of these metrics require no separate instrumentation to collect. Drift rate, gate-bypass frequency, and corrections-per-phase can be derived directly from existing records rather than a new measurement system. And "is this working" only means something aggregated at the org level, a single team's numbers can't answer it. This isn't new territory either; the platform already instruments deploy pipelines org-wide, so this is just a new set of queries against data it's already capturing.
Fixing weak operations coverage with a living-spec feedback loop
Almost every agentic development framework is thickest at the front end, planning, specification, code generation, and thins out sharply once code reaches production. Deployment and monitoring exist but get treated as the end of the process, not a source of feedback into it. When production reveals a spec was wrong, an edge case nobody anticipated, that discovery stays in the incident tracker and rarely makes it back to the spec that caused it, so the same gap resurfaces later because nothing closed the loop.
The fix is a living-spec feedback loop: production incidents become entries in the same ledger as everything else, linked back to the spec version and code that produced them, so an incident can automatically trigger a spec-update proposal instead of living only in one engineer's memory. This needs no new infrastructure, platform engineering already owns deploy and monitoring, so the telemetry already exists; what's missing is a consumer treating that data as input to the spec process rather than its endpoint. Operations stops being an afterthought: an incident updates the spec that should have prevented it, so the next agent in that part of the codebase inherits the correction instead of repeating the gap.
Fixing supply-chain risk with an internal, vetted registry
The agentic development ecosystem runs heavily on community-contributed skills, templates, and extensions, almost none of it vetted before a team installs it. A skill might request broad file access, run arbitrary commands, or reach external networks, with no visibility into any of that before it's already running. Compounding this, maintainers can disappear without warning, so a team's workflow quietly depends on something nobody's securing anymore.
The fix is an internal registry with vetting; the same pattern platform teams already use for package registries. A skill only becomes installable org-wide once reviewed and signed off, with what it touches declared up front. That review record lives at the platform level, not with the author, so it persists even if the maintainer disappears, and because one authoritative place enforces it, the review holds. Supply-chain risk stops being invisible: an extension either carries a signed manifest, or it isn't installable.
Fixing the missing brownfield path with a golden path variant for legacy systems
Nearly every agentic development framework assumes a greenfield starting point, a new project, an empty repo, a spec from scratch. But most real work happens against existing systems that don't come with a spec an agent can read; domain knowledge is usually implicit, embedded in the code, undocumented edge cases, decisions nobody wrote down. Every team touching a legacy system ends up reconstructing that context by hand, treating brownfield work as a one-off exception rather than something the process supports.
The fix is a golden path variant for legacy systems: a platform-provided extraction path that recovers a working spec directly from the existing codebase, labeling each piece with a confidence level and any known gaps, then writes it into the ledger like any other spec version. This only pays off if it's reusable across every legacy system an org runs rather than rebuilt per team, the same logic as the golden paths already defined for new projects, extended to older ones. Brownfield stops being the exception nobody planned for: a team inherits a recovered spec with its confidence and gaps marked, entering the same traceable chain as everything else the platform tracks.
Putting it together: a reference architecture
At the center of the architecture sits the IDP core, which hosts the shared provenance ledger, since every other component exists to feed data into it or read from it, making the IDP the spine the rest of the system connects to. Work enters the system through the golden path and scaffolding layer, which wires in the process manifest, the required gates, and the ledger connection automatically the moment a team starts a new project; this layer also includes a legacy-system variant that runs specification recovery instead of assuming a blank spec, so brownfield and greenfield work both begin from the same entry point rather than brownfield being handled as a special case. As an agent works, two layers police that work in real time: guardrails middleware intercepts every prompt, file read, and tool call as it happens, and a context and knowledge service supplies the agent with org-wide grounding, such as architectural decisions, service ownership, and domain constraints, so it isn't working from whatever an individual engineer happened to paste into a prompt.
Sitting underneath both the golden path's required approvals and the guardrails' security checks is a gate engine, which is what makes those checks binding rather than advisory: a change can't merge without a logged gate decision, and any bypass must be logged with a justification rather than silently skipped. Anything an agent pulls in beyond the core system, such as a community skill or a template, must come from the internal skill and template registry, which only allows in extensions that have passed a signed-manifest review. And once code ships, the observability loop closes the circle: production telemetry flows back into the ledger, and a production incident can trigger a spec-update proposal automatically, rather than that discovery living only in an incident tracker disconnected from the spec that caused it.
Walking through the architecture as a sequence
- A team starts from a golden path template, greenfield or legacy, the only entry point into the system, which automatically wires in the process manifest, required gates, and ledger connection.
- A context compiler pulls the agent's grounding, such as architectural decisions, service ownership, and domain constraints, from the shared context service and logs its sources to the ledger.
- The agent executes in an isolated workspace, which is what makes per-change traceability and clean gate evaluation possible. If the agent pulls in a community skill or template during that work, it must come from the internal skill and template registry, which only admits extensions that have passed a signed-manifest review.
- Guardrails middleware inspects prompts, file reads, and tool calls in real time and blocks violations the moment they happen, not after the fact.
- The gate engine evaluates the change against the golden path's required rules and blocks the merge until a decision, or a justified bypass, is logged.
- The ledger records the full chain into one unbroken entry: spec version, context, code, test result, review decision, deploy, and any resulting incident.
- Telemetry, such as drift rate, bypass frequency, and review load, surfaces directly from the ledger's existing data, so no separate instrumentation is needed. When production later surfaces an incident, that same telemetry automatically triggers a spec-update proposal, closing the loop back to the spec version that should have prevented it.
Treating the framework as a platform product means a platform team owns it end-to-end: clear ownership, a versioning and deprecation policy, feedback loops, and adoption earned through good golden paths rather than through mandate. It rolls out incrementally, from a single template to full governance tooling.
Conclusion
Many frameworks and acronyms have emerged, and adoption keeps rising even as impact hasn't followed. Every framework does something genuinely useful, but each also breaks in a specific way, and those breaks aren't random: they cluster into eight recognizable shapes, all tracing back to one gap. Spec, context, code, tests, decisions, and security checks are tracked as disconnected artifacts with no shared layer connecting them across tools, teams, or time. That's why the fix here isn't another framework but the infrastructure layer none of the existing methodologies have, built the way platform teams already build shared infrastructure for everything else: a provenance ledger that turns drift into something queryable, golden paths that dissolve the false choice between process depth and portability, guardrails and context services that stop being rebuilt independently by every team, a registry that brings supply-chain trust to a category of software that currently has barely any, and a living-spec loop that finally gives production a voice in the process that planning has always had.
The reference architecture makes this concrete rather than aspirational, with one ledger at the center and every other component reading from or writing to it, and it's a proposal a platform team could start building tomorrow with one golden path and a basic set of gates. It isn't a finished result: real process depth costs real overhead, no amount of infrastructure replaces a qualified reviewer's judgment, and this remains an architecture rather than an outcome measured on a real team over real time. The invitation isn't to adopt a new acronym; it's to notice that the industry has spent a year building better processes for agents to follow and almost no time building the infrastructure to hold those processes together, and platform engineering is already equipped to close that gap, one golden path at a time.
