Agentic SDLC for enterprise teams: closing the context gap between discovery and code

An agentic SDLC is a software development lifecycle where AI agents carry out work at each stage, such as drafting specs, writing code, testing and reviewing, within limits that people set. At enterprise scale, it breaks down at the context gap: the decisions, evidence and constraints that never reach the agents doing the work.

Your agents can open a pull request in twenty minutes. Getting four teams to agree on what that pull request should do can still take three weeks. In a small team, the people who decided and the people who build sit in the same channel, so missing context gets filled in by asking. In a company with forty teams, each agent works from the slice of context its own team wrote down, and most of the reasoning lives somewhere else.

Most writing on the agentic SDLC covers agent autonomy and delivery governance. This post covers the step before that: what agents need to know before they act, and how an enterprise gets it to them. For the wider argument that product and engineering lifecycles are merging, start with the AI SDLC is really a product lifecycle.

The agentic SDLC in one diagram

• Evidence: humans
• Decision: humans
• Spec: agent drafts, humans approve
• Build: agent
• Test: agent
• Review: agent + human
• Release: humans approve

Each stage has an agent with bounded authority. A spec agent can draft acceptance criteria but can't change scope. A coding agent can change files in one repository but can't merge. A test agent can add tests but can't delete failing ones to get a green build. People own the two ends: choosing the problem and approving what ships.

The inputs on the left set the quality of everything to the right. A coding agent with perfect tools still builds the wrong thing if the decision it received was thin.

Why the agentic SDLC is harder in the enterprise

Enterprises add five things that make context harder to move.

Team count. One feature can touch a mobile team, a platform team, a data team and a compliance function. Each has its own backlog and its own idea of what the feature is.

Handoffs. Every handoff is a place where reasoning gets compressed. A two-hour discovery workshop becomes a ten-line ticket. The agent reading the ticket gets the ten lines.

Compliance. Regulated work carries rules that can't bend: data residency, retention, audit trails, accessibility. Those rules often live in policy documents the delivery team never opens.

Legacy. Old systems have behaviour nobody documented. The person who knows why the batch job runs at 2 a.m. is in a meeting, and the agent can't ask them.

Many tools. Discovery notes sit in Notion or Confluence, designs in Figma, work in Jira or Linear, code in GitHub. Each tool holds part of the story, and none holds the decision.

What is the context gap?

The context gap is our name for the distance between what an organization has decided and what an agent receives when it starts a task. It's our own framing. We split it into five kinds of missing context.

1. Decision context. What problem this solves, which approach the team chose and what it rejected.
2. Evidence context. The research, support tickets or data that justify the work.
3. Scope and boundaries. What's in, what's out and which systems the task must not touch.
4. Constraints. Rules that can't bend, such as legal, security, performance and brand.
5. Acceptance. How a reviewer will know the work is done, including product intent and not only passing tests.

An illustrative example

This example is made up. An insurer decides to let customers change their home address in the mobile app instead of calling. Four teams pick up work, and each gives its agent a ticket.

The mobile team's agent gets "Add address change screen." It builds a clean form. It doesn't know that a change of address can change the premium, because that decision was made in a pricing meeting the mobile team didn't attend.

The policy platform team's agent gets "Expose address update endpoint." It writes the endpoint and updates the address immediately. It doesn't know compliance requires the old address to be kept for seven years, because that rule lives in a retention policy PDF.

The notifications team's agent gets "Send confirmation email." It sends one to the new address. Nobody told it that the fraud team asked for a notice to the old address too, which is the standard check against account takeover.

The data team's agent gets "Update address in the warehouse." It overwrites the field, which breaks a regional risk report that depends on address history.

Every agent did its task well, and every pull request passed its tests. The feature still fails review, because the decision, the constraints and the acceptance criteria were split across four teams and never assembled for any of them.

Symptoms of the context gap in an agentic SDLC

• Rework. Pull requests get rejected for reasons that weren't in the ticket.
• Conflicting pull requests. Two teams' agents make incompatible assumptions about the same data or flow.
• Agents guessing. An agent fills a missing detail with a plausible default instead of asking. Plausible defaults are the hardest bugs to catch in review.
• Agents re-asking. The same clarifying question comes up in three teams in the same week.
• Review bottleneck. Senior engineers and PMs become the only place where full context exists, so every pull request queues behind them.

The last one is the most expensive. Agents speed up writing code, and if context only lives in a few heads, review becomes the new queue.

How to close the context gap

No single tool closes it. These five practices narrow it.

Keep one source for decisions

Pick one place where decisions live as records: the problem, the evidence, the chosen approach and the rejected options. Tickets and specs link to the decision instead of paraphrasing it. When the decision changes, the change shows up everywhere that links to it.

Version and scope context per task

An agent working on the notifications service doesn't need the full pricing analysis. It needs the parts that apply to its task, and it needs to know which version of the decision it's working from. Scoped context is shorter and easier for agents to follow. Versioned context lets a reviewer check whether the agent worked from an outdated decision.

Use MCP as the access path

The Model Context Protocol describes itself as "an open-source standard for connecting AI applications to external systems." MCP servers let a coding agent read from the tools where your context lives. That solves access. It doesn't decide which context is current, relevant or approved. An agent with MCP access to a messy Confluence space can read the messy Confluence space.

Set repository norms in rule files

Repository conventions, such as code style, test commands and folders agents must not edit, belong in rule files the agent loads with the code. We compare the formats in AGENTS.md vs CLAUDE.md vs Cursor rules. Rule files cover how to work in a repo. They don't carry product decisions.

Hand each task a decision brief

The decision brief is the unit that crosses the gap. For the address change example above, the platform team's agent might receive this:

This example is illustrative. A full guide to writing these is in how to give AI coding agents product context, and specs built from them are covered in spec-driven development for product teams.

Governing context in an agentic SDLC

Context needs owners, like code does. Settle four questions before you scale.

Ownership. Who can change a decision record? Usually the PM who owns the bet, with named approvers for constraints like compliance or security.

Freshness. How do agents know a decision is current? Give records a status and a last-reviewed date, and treat an expired record like a failing check.

Permissions. An agent should see the context its task needs and no more. Mirror the access rules people already have, so an agent can't read a document its requester couldn't.

Audit. When a pull request ships, you should be able to trace which decision and which version the agent worked from. That trace is what lets you tell a bad decision apart from a bad execution.

A 30-day agentic SDLC rollout checklist for one team

Start with one team and one feature.

Week 1. Pick a feature that crosses at least one team boundary. Write its decision record: problem, evidence, decision, rejected options, constraints, done criteria. Name an owner.

Week 2. Break the work into tasks and write a decision brief for each one. Add or tidy the rule file in each repository involved. Connect agents to the decision record through whatever access path you already use, such as MCP or a pasted brief.

Week 3. Run the tasks with agents. Log every clarifying question an agent asks and every assumption a reviewer catches. Each one points to context that was missing from the brief.

Week 4. Review the log with the team. Fold the missing context back into the decision brief template. Decide whether to extend the approach to a second team.

The logged questions are the useful output. They tell you exactly which kinds of context your briefs were missing.

What this can't fix

Better context transport doesn't make the context better.

• Bad decisions. If the team chose the wrong problem, agents will build the wrong solution faster and more faithfully.
• Missing evidence. If nobody did the research, a decision record can only say so. It can't invent the evidence.
• Org misalignment. If two directors disagree about scope, writing it down surfaces the disagreement. Someone still has to settle it.

Each of these is a human job. In an agentic SDLC, people steer and agents execute, and steering includes deciding what's worth building.

Where SteerFlow fits in the agentic SDLC

Go back to the diagram. Agents run the stages from spec to release. SteerFlow is designed for the stages to the left of them, as the product context layer between what your organization decides and what your agents receive. It is designed to keep evidence and decisions as records, scope them into briefs for each task, and keep that context attached as work moves between teams, so each agent starts from the same decision instead of its own slice of it. If your teams' agents keep working from different versions of the truth, we'd like to compare notes. Get in touch.