Część II: Standaryzacja AI w SDLC na poziomie organizacji

W poprzedniej serii doszliśmy do managed agenta. Agent nie był już tylko czymś uruchamianym w local environment. Mógł działać jako osobny workload i wykonywać zadania samodzielnie.

Ta seria zaczyna się dokładnie w tym miejscu. Jej tematem jest standaryzacja AI w SDLC na poziomie organizacji.

Zakładamy, że managed agent już istnieje i potrafi wykonywać pracę w SDLC. Nie będziemy więc ponownie budować agenta ani tłumaczyć podstaw agentic workflow.

Jako stały punkt odniesienia wykorzystamy istniejącego Implementer Agenta, czyli rolę, która potrafi pobrać task, pracować na repozytorium, uruchomić testy i przygotować pull request.

Interesuje nas teraz coś innego:

Co trzeba przenieść z poziomu pojedynczego agenta i pojedynczego zespołu na poziom organizacji, żeby taki sposób pracy był ustandaryzowany, kontrolowany, bezpieczny i obserwowalny?

Na kolejnych etapach nie dokładamy agentowi nowych „supermocy”. Wynosimy jego otoczenie do wspólnych capability organizacji: modele, triggerowanie, dostęp do repozytoriów i narzędzi, RAG, runtime, state, observability, security i evals.

Problem nie brzmi już:

Czy agent potrafi zaimplementować task?

Tylko:

Jak sprawić, żeby dziesiątki takich agentów działały według wspólnych zasad, korzystały z zatwierdzonych modeli i integracji, były obserwowalne, bezpieczne i możliwe do kontrolowania?

task
|
v
agent
|
v
kod

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

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

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

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