An enterprise AI platform can begin with a model gateway and a developer portal. That is useful. It can give teams one route to approved models, consistent access, cost controls and evaluation traces. But it is still a model platform.
The architecture changes the moment an agent may edit a repository, execute a tool, open a pull request, create an environment or influence a release. The platform has entered the software delivery lifecycle, whether its roadmap calls that out or not. Model access is now the smaller problem. Identity, authority, evidence, promotion and recovery become the consequential ones.
My recommendation is blunt: an AI platform needs an SDLC platform first.
I do not mean that an ISO standard requires a product called an “SDLC platform”, or that every delivery capability must sit inside one central control plane. This is an architectural completeness test. By SDLC platform I mean the integrated capabilities and contracts which carry a change from accepted intent through versioned work, independent verification, environment promotion, production observation and recovery. They may be federated across several teams and tools.
If a company cannot give a non-human actor bounded access to repositories, tools, CI and environments without lending it a developer’s session, then it has an assistant attached to an informal delivery system. A more capable model will make that informality move faster.
The loop AI compresses, and the loop it does not
Inner loop and outer loop have several meanings in software engineering, so I need to be precise about mine here.
The inner loop is the bounded execution which turns accepted intent into a proposed, tested and evidenced change. It includes reading the current system, changing artifacts, invoking tools, running tests and evaluations, responding to failures, and preparing a delivery candidate.
The outer loop defines the intent, risk, acceptance conditions, production authority and accountability under which that execution may proceed. It decides what is worth changing, what evidence is enough, which residual risk can be accepted, how far a rollout may go, and when the system must stop.
Contemporary coding agents compress the inner loop rather dramatically. An agent can inspect a repository, change code and tests, run the build, analyze a failure and revise the patch during one run. In a well-bounded change class it can own most of that execution.
The outer loop does not disappear as a result. The organization still owns the requirement and the acceptance policy. Automation can apply that policy, but an accountable role still owns its exceptions and residual risk. Production still needs a promotion rule. And somebody still owns the outcome when a technically correct change produces the wrong product behavior.
“The model decided” is neither an authority model nor a useful incident response.
Follow one change all the way through
Consider a deliberately ordinary request: add one eligibility rule to an existing product capability, keep the old behavior as the control, and release the change behind an existing feature flag. No new customer attributes. No data migration. One service and its existing telemetry.
Bounded does not mean harmless. It means the platform has enough information to draw a meaningful envelope around the work.
Intent arrives with a production boundary
Before execution, the outer loop records the expected behavior, non-goals, eligible population, data constraints, acceptance checks, rollout ceiling and recovery condition. It identifies an owner and classifies the change as eligible for agent execution.
This is where requirements become operational. “Add an eligibility rule” leaves an agent to infer whether it may change a schema, introduce a service dependency or affect every user. The non-goals matter because the agent can explore and implement those inferences far more quickly than a reviewer can later unwind them. Speed magnifies ambiguity.
Delegation creates a new principal
The platform starts the run with an attributable workload identity. That identity receives time-bounded, least-privilege access to the repository, approved documentation, an isolated execution environment and the specific tools needed for the task. It does not inherit the engineer’s broad session. It does not receive a long-lived production credential.
Capability and authority are separate properties. A model may be capable of operating a deployment tool; IAM determines whether this run can call it, against which environment and with which parameters. Repository instructions may explain that production configuration is out of scope. Policy has to make the boundary real.
This separation is easy to miss in a human-centered internal developer platform. The authenticated engineer arrives with identity, contextual judgment and authority bundled together. Once the platform admits agents, it must be able to answer four distinct questions: which principal acted, who or what delegated the task, which capabilities were reachable, and which approval could widen the authority envelope.
The run needs operational limits as well: wall-clock and cost budgets, context limits, maximum fan-out, bounded retries, checkpoints and a stop rule for repeated failure. When it stops, it should leave completed work, evidence, unresolved risk and the next decision in a resumable state. Telling an agent to avoid loops is reasonable guidance. It is not a circuit breaker.
Git turns work into a proposal
The agent branches from a known commit and produces the smallest coherent change. The repository contract supplies owners, required commands, generated-file rules, prohibited paths and the evidence expected for this change class. The result is a versioned proposal with a diff and provenance, rather than an invisible mutation in a shared environment.
This is Git-mediated delivery; it is not automatically GitOps. The OpenGitOps principles describe a narrower contract for managed system state: declarative desired state, versioned and immutable state, automatic pull, and continuous reconciliation. Where those conditions hold, GitOps can carry accepted state into an environment. Elsewhere, Git remains a very useful proposal and audit boundary without acquiring the GitOps label.
That distinction is not pedantry. If everything involving Git is called GitOps, we lose the ability to ask who reconciles declared state, how drift is detected, and whether an imperative action has bypassed the reviewed path.
CI must be allowed to disagree
The agent can run fast checks locally. CI independently rebuilds the candidate and runs the tests, security checks, policy rules and task-specific evaluations required by its risk class. For this change, it might verify that the old behavior remains available, the new rule stays within its data boundary, the flag defaults safely and the telemetry contract is present.
Independence is the important word. If the proposing actor can change or bypass the protected verifier, its credentials, fixtures or acceptance policy for the same proposal, green CI means rather less than it appears to mean. A change to its own verifier should enter a stronger review class.
Some evaluation evidence will be statistical or model-based rather than bit-for-bit deterministic. The evidence can vary while its binding remains strict: evaluator and model versions where feasible, protected fixtures, declared sample counts and thresholds, uncertainty treatment, candidate digest, and a recorded decision. The agent’s assertion that the tests passed is not part of this evidence model.
NIST SP 800-204D is security and supply-chain guidance for cloud-native DevSecOps, rather than a complete AI operating model. Its treatment of repositories, pipelines, provenance, policy, testing and deployment as practical control points is still useful here. The delivery machinery is where many intentions finally become enforceable facts.
A green build earns a candidate, not production
The build produces an immutable artifact with provenance. Environment-specific configuration remains separately versioned. The same candidate moves through an isolated test environment and then through whatever staging or acceptance path the risk policy requires. Contract tests, integration checks, security review, AI-specific evaluations where relevant, and product acceptance run against the artifact which may actually be promoted.
Repository correctness is not system correctness. The eligibility decision may depend on a service whose staging data is stale. The flag client may fail in a way the unit tests never exercise. Telemetry can be syntactically valid and semantically useless. Environments let evidence accumulate before authority increases.
Production promotion is a separate decision even if the agent executed every preceding step. A release record binds the accepted commit, artifact digest, provenance, configuration, evidence, approver, rollout limit and recovery plan. A deployment principal, distinct from the coding principal, performs the promotion.
I would not prescribe one canary percentage or a mandatory human click for every change. Low-risk and genuinely reversible work can earn more automation. A high blast radius, weak observability, sensitive data or irreversible effects require stronger acceptance. The invariant is that authority grows only when the required evidence and policy permit it.
During rollout, technical and product guardrails are evaluated against the release record. If a stopping condition fires, the platform invokes a tested, pre-authorized recovery action: disable the flag, roll back, restore or roll forward, depending on the system. Stateful effects may not be reversible at all. That uncomfortable detail belongs in the acceptance decision, before an incident turns rollback planning into archaeology.
Whether the rollout succeeds or stops, the platform records the observed result, the decision and the resulting state. Temporary authority expires. Only then is the delivery loop complete.
What changes when the platform admits agents
The familiar IDP remains valuable. Agents need the same build, test, delivery, observability, identity, secrets, artifact and policy capabilities that engineers need. The CNCF Platforms White Paper describes a platform as an integrated collection of capabilities exposed through consistent interfaces. It is cloud-native community guidance, not an AI-specific standard, but the underlying integration point holds.
The actor model changes the contract around those capabilities:
| Human-centered assumption | Human-and-agent platform contract |
|---|---|
| The authenticated user supplies judgment and notices when work has gone off course | Identity, delegator, reachable tools, budgets, stop conditions and escalation are explicit |
| A developer interprets repository convention and tribal knowledge | Ownership, commands, prohibited paths and validation expectations are machine-readable and policy-backed |
| Interactive attention supervises tool use | Tool calls have bounded parameters, data and network reach, and attributable results |
| A green pipeline returns control to a person who understands its context | Evidence is bound to an immutable candidate and consumed by an explicit acceptance policy |
| Human credentials may span proposal and release | Proposal, acceptance and production promotion have distinct principals and audit records |
This does not require an enormous central platform team. Repository owners can define local tests. Security can own identities and policy. Platform engineering can own CI, artifacts and environment promotion. Reliability teams can own operational guardrails; product and data teams can own acceptance and outcome measures.
Federation works if the contracts are shared: attributable identity, bounded authority, portable evidence, consistent meanings for promotion stages, and recovery which does not require negotiating the organization chart during an incident. Centralizing every mechanism produces a bottleneck. Standardizing none of the invariants produces an audit gap.
Governance follows the lifecycle
AI governance is often narrowed to model selection, prompt policy and an evaluation dashboard. The formal guidance is broader. ISO/IEC 5338:2023 addresses AI system lifecycle processes; ISO/IEC 42001:2023 defines an organizational AI management-system standard; the voluntary NIST AI RMF 1.0 and its Generative AI Profile organize risk work across governance, context, measurement and management.
None of those sources says “buy an SDLC control plane”. An organizational management system is also not a software platform. The narrower inference is enough: responsible AI work spans design, development, deployment, use, monitoring, assessment and improvement. For software-changing agents, the SDLC platform is where a large part of that lifecycle becomes executable. It connects intent to repository state, identity to tools, evidence to promotion, and a deployed change to observation and recovery.
The investment decision
I have written separately about safe delegation capacity and CI as an authority boundary. The narrower question here is whether the delivery path is complete.
Leaders evaluating an AI platform should ask:
- Can an agent receive a bounded identity without impersonating an employee?
- Can it reach the tools required for a task while remaining unable to cross the production boundary?
- Can protected CI independently verify the exact candidate and preserve the evidence used to accept it?
- Can production authority increase in proportion to risk, reversibility and observed evidence?
- Can the organization stop, recover and explain the resulting state, including effects which cannot simply be rolled back?
If the answer is no, do not begin by shopping for a cleverer agent. Turn the failure into the platform backlog: identity, reproducible candidates, protected verification, promotion boundaries, execution budgets, observability and tested recovery.
Those investments improve delivery for people too. More importantly, they give the business a serious measure of AI-platform progress: how much additional work can reach production without borrowing authority or losing accountability?