What a standardized Agentic SDLC looks like
- date
- category
- AI Agents
- also in
- AI Engineering · Engineering Practices
- reading
- 3 min / 645 words
We started with a managed agent.
We did not add services because they exist.
Each element showed up because at organizational scale a concrete problem appeared.
The Implementer Agent's final flow looks like this:
JIRA
issue -> Ready for AI
|
v
TRIGGER
Jira Automation / event layer
|
v
MANAGED RUNTIME
Foundry / AgentCore / Vertex
|
v
IMPLEMENTER AGENT
|
v
jira.get_issue(PAY-123)
|
v
create workspace
|
v
git clone payments-service
|
v
read AGENTS.md
|
v
need external knowledge?
|-- no
`-- yes -> RAG
|
v
implement
|
v
run tests
|
v
GitHub tool / MCP
|
v
create PR
Around this flow the organization provides:
models
identity
policies
state / memory
observability
security controls
evals
What the organization standardizes
| Area | What is shared |
|---|---|
| Trigger | how agent roles are started from SDLC events |
| Models | approved models and how they are accessed |
| Agent template | the base structure of an agent repo |
| Workspace | bootstrap, clone, branch, base image |
| RAG | shared engineering knowledge sources |
| Tools | approved MCP/tools and auth |
| Runtime | hosting, identity, scaling |
| State / memory | the durability mechanism |
| Human-in-the-loop | pause/resume, question channels, timeout and escalation |
| Observability | traces, logs, metrics, dashboards |
| Security | guardrails, DLP, tool policies |
| Evals | how behavior is measured and quality gates |
Evals are part of the agent's normal lifecycle
Evals are not a one-off test run at the first deployment.
In practice the organization can adopt a simple rhythm:
every agent PR
-> small regression suite
model / prompt / RAG / tools change
-> extended suite
release
-> full regression + baseline comparison
production
-> sampling of real traces
periodically
-> another full regression
That way the agent is controlled like other parts of the SDLC: not just before the first deployment, but across its whole lifecycle.
What the team still defines
The team is still responsible for what its role means.
For the Implementer Agent it decides:
- when a task is ready,
- what the agent is supposed to achieve,
- which repo and workflow it handles,
- which tools it needs,
- which instructions are product-specific,
- which eval cases really represent correct work.
Agent roles
The Implementer Agent is only the first example.
You can build others the same way:
Reviewer Agent
-> started on a PR
Incident Agent
-> started on an incident
Release Agent
-> started before a release
Each role has its own internal workflow.
We do not create a separate agent for every step.
Implementer Agent:
ticket
-> code
-> tests
-> PR
Reviewer Agent:
PR
-> diff
-> context
-> review
Tools: a market map
| Layer | Azure | AWS | GCP | Independent |
|---|---|---|---|---|
| Models / AI platform | Microsoft Foundry | Amazon Bedrock | Vertex AI | direct provider APIs |
| Events | Event Grid / Functions | EventBridge / Lambda | Eventarc / Cloud Run | webhooks |
| Runtime | Foundry Agent Service | AgentCore Runtime | Vertex AI Agent Engine | Kubernetes |
| RAG | Azure AI Search | Bedrock Knowledge Bases / OpenSearch | Vertex AI RAG Engine | Pinecone, Weaviate |
| Tools / MCP | Foundry tools / MCP | AgentCore Gateway | Agent Gateway / MCP | your own MCP |
| State / memory | Foundry state / Cosmos DB | AgentCore Memory | Sessions / Memory Bank | your own layer |
| Observability | App Insights / Foundry Tracing | CloudWatch / AgentCore Observability | Cloud Trace / Monitoring | OpenTelemetry, Langfuse |
| Security | Foundry Guardrails / Prompt Shields | Bedrock Guardrails / AgentCore Policy | Vertex safety / DLP | custom controls |
| Evals | Foundry Evaluations | Bedrock / AgentCore Evaluations | Vertex Gen AI Evaluation | LangSmith, Phoenix |
The biggest change since the previous series
In the previous series we asked:
How do you build and run an effective agent?
Here the question is different:
How do you let many teams build different agent roles on a shared platform while the organization still knows what those agents do, what they have access to, how much they cost and whether they work correctly?
That is the next stage: standardizing AI in the SDLC across the organization.
Not more autonomy for one agent.
More standardization, observability and control around the whole way of working with agents.