Konrad Kowalski (rootsher)Principal Platform & Reliability Architect010001011111001000001110100110000011000010010010

Part II: Standardizing AI in the SDLC Across the Organization

date
category
AI Agents
also in
AI Engineering · Retrieval & Knowledge · Automation · Engineering Practices
reading
2 min / 492 words

In the previous series we got as far as a managed agent. The agent was no longer something you ran in a local environment. It could run as a separate workload and carry out tasks on its own.

This series starts exactly there. Its subject is standardizing AI in the SDLC across the organization.

We assume the managed agent already exists and can do work in the SDLC. So we will not build an agent again or explain the basics of agentic workflows.

As a fixed point of reference we will use an existing Implementer Agent: a role that can pick up a task, work on a repository, run the tests and prepare a pull request.

What interests us now is something else:

What has to move from the level of a single agent and a single team to the level of the organization, so that this way of working is standardized, controlled, secure and observable?

In the following steps we do not give the agent new "superpowers". We move its surroundings into shared organizational capabilities: models, triggering, access to repositories and tools, RAG, runtime, state, observability, security and evals.

The problem is no longer:

Can the agent implement a task?

But:

How do you get dozens of such agents to follow shared rules, use approved models and integrations, and stay observable, secure and controllable?

The flow we will build out

At the start we have a simple managed agent:

text
task
|
v
agent
|
v
code

At the end we want:

text
Jira
|
v
trigger
|
v
Implementer Agent
|
v
managed model
|
v
workspace + repo
|
v
RAG
|
v
approved tools / MCP
|
v
state / memory
|
v
PR
|
v
observability + security
|
v
evals

These are not independent blocks dropped into an architecture diagram.

Each of them shows up because at a larger scale it starts to be needed.

Four places for configuration

Throughout the series we will distinguish four places.

Product repo

This is where things specific to one application live:

text
payments-service/
├── AGENTS.md
├── src/
├── tests/
└── docs/

Agent repo

This is where the logic of the Implementer Agent role lives:

text
engineering-agents/
└── implementer/
    ├── agent.py
    ├── workflow.py
    ├── workspace.py
    ├── tools.py
    └── evals/

Organizational platform

This is where the organization exposes shared capabilities:

  • models,
  • RAG,
  • tools and MCP,
  • identity,
  • runtime,
  • memory,
  • telemetry,
  • guardrails.

Trigger / pipeline / event layer

This is where we define:

When do we start which agent?

For example:

text
Jira issue -> Ready for AI
|
v
Jira Automation / webhook
|
v
Implementer Agent

Structure of the series

  1. Starting the agent from a real event
  2. Standardizing models
  3. Agent repo and workspace
  4. RAG as shared organizational knowledge
  5. MCP, tools and central access
  6. Managed runtime, state and memory
  7. Human-in-the-loop
  8. Observability, security and control
  9. Evals and quality gates
  10. The final Managed Agentic SDLC

The goal is not to learn the service catalogs of Azure, AWS or GCP.

The goal is to understand exactly what has to be added after the single managed agent stage for Agentic SDLC to become a controlled capability of the organization.

Materials

top