Poziomy agentowości w systemach AI
Poziomy agentowości w systemach AI
Podczas pracy nad https://github.com/pawel-dubiel/AgentMachine zastanawiałem się jakie możemy mieć role agentów, z których można potem budować bardziej skomplikowane flow. A znowu ten nowe flowy jak klocki można wpinać w ogromne
systemy. Kojarzy mi się to z fraktalową architekturą.
Oraz na którym poziomie system naprawdę podejmuje decyzje i jakie?
Rozróżnienie: workflow vs agent
Wiele rzeczy nazywanych "agentami" to tak naprawdę to zwykłe LLM workflows.
Workflow to są kroki są z góry zaprojektowane w kodzie. Na przykład: klasyfikuj request → zrób search → podsumuj → zwróć wynik.
Agent to model, który sam dynamicznie decyduje, co dalej. Jakich narzędzi użyć, czy podzielić zadanie, czy kontynuować, czy poprosić innego agenta. Można mieć systemy gdzie LLM-y i narzędzia są prowadzone przez zdefiniowane ścieżki. Różnią się znacząco od agentów, które same kierują swoim procesem i użyciem narzędzi.
im większe ryzyko i bardziej powtarzalny proces, tym więcej deterministycznego workflow. im większa niepewność i eksploracja, tym więcej agentowości.
Gdzie jest "agency"
Ostatnio miałem rozmowę, ktoś mnie próbował przekonać, że predefiniowany workflow który korzysta z sieci LLM to system agentowy. Zupełnie nie zgadzam się z taką definicją. W związku z projektem własnego harnessu agentowego zacząłem się zastanawiać na różnymi poziomami agentowości.
Na którym poziomie system ma swobodę decyzyjną?
Claude Code i Codex są głównie Poziomem 4–5,
z funkcjami, które pozwalają budować Poziom 6–7,
ale same z siebie nie są jeszcze Poziomem 8.
Te poziomy to na razie moja własna interpretacja, oczywiście rzeczywistość jest bardzo "płynna" i wszelkie podziały są bardzo umowne.
| Level | Name | Core idea | Agency level |
|---|---|---|---|
| 0 | Tool | Executes a single predefined action. | None |
| 1 | Static Workflow | Executes a fixed sequence of predefined steps. | Near zero |
| 2 | Dynamic Workflow | Executes predefined steps with predefined branches. | Low |
| 3 | Agent inside Workflow | A mostly deterministic workflow contains one or more agentic steps. | Local |
| 4 | Task Agent | An agent chooses the steps and tools needed to complete a given task. | Task-level |
| 5 | Flow Designer Agent | An agent designs a custom workflow for a specific task. | Process-level |
| 6 | Workflow Factory | A system generates workflows from predefined templates or rules. | Meta-workflow, but mostly deterministic |
| 7 | Agentic Workflow Factory | An agent generates, runs, evaluates, and adjusts workflows based on goals and feedback. | Adaptive meta-agency |
| 8 | Self-improving Agentic OS | The system improves the rules and strategies used to create future workflows. | System-level self-improvement |
każdy level odpowiada na inne pytanie:
Tool: What action can be executed?
Workflow: What process should be followed?
Dynamic Workflow: Which predefined branch should be taken?
Agent inside Workflow: Where can local reasoning happen?
Task Agent: How should this task be solved?
Flow Designer Agent: What workflow does this task need?
Workflow Factory: Which template-generated workflow should exist?
Agentic Workflow Factory: What new workflow should be created and adapted?
Self-improving Agentic OS: How should the system improve its way of creating workflows?
Role Agentów
| Typ agenta | Rola | Kiedy ma sens |
|---|---|---|
| Triage / Intake Agent | Rozumie, czego chce użytkownik. Czy to pytanie, research, kodowanie, operacja na plikach, debug, deployment? | Na wejściu do systemu. |
| Router Agent | Wybiera ścieżkę: chat, simple tool flow, agentic task, human review, odmowa, eskalacja. | Gdy masz wiele możliwych workflow. |
| Planner Agent | Rozbija zadanie na kroki, zależności i podzadania. | Przy większych taskach: kod, analiza, migracja, research. |
| Orchestrator / Supervisor Agent | Koordynuje wielu workerów, pilnuje celu, zbiera wyniki. | Multi-agent, swarm, parallel work. |
| Worker / Specialist Agent | Wykonuje konkretną pracę: coding, research, SQL, testy, dokumentacja, UX copy. | Gdy różne role wymagają innych promptów i narzędzi. |
| Tool-Using Agent | Używa narzędzi: shell, GitHub, DB, browser, Jira, Stripe API, filesystem. | Tam, gdzie model musi działać na świecie zewnętrznym. |
| Research / Context Agent | Zbiera kontekst z repo, dokumentów, internetu, logów, issue, historii rozmowy. | Przed planowaniem albo przed wykonaniem. |
| Executor Agent | Realnie wykonuje kroki: zmienia kod, tworzy pliki, odpala testy, robi zapytania. | W coding agentach i ops automation. |
| Critic / Reviewer Agent | Sprawdza wynik innego agenta: błędy, luki, niespójności, edge case’y. | Przy kodzie, decyzjach architektonicznych, dokumentach. |
| Evaluator / Optimizer Agent | Ocena → feedback → poprawa → ponowna ocena. | Dobre do jakości tekstu, kodu, planów, analiz. |
| Guardrail / Safety Agent | Waliduje input/output/tool calls. Może blokować lub wymagać approval. | Przy ryzykownych operacjach, danych wrażliwych, shellu, produkcji. |
| Memory / State Agent | Zarządza pamięcią, streszczeniami, decyzjami, kontekstem sesji. | Przy długich zadaniach i agentach działających przez wiele kroków. |
| Observer / Progress Agent | Informuje użytkownika, co się dzieje, ale nie wykonuje głównej pracy. | W długich taskach, żeby użytkownik nie był “w ciemności”. |
| Human Proxy / Approval Agent | Zatrzymuje flow i prosi człowieka o decyzję. | Przed deployem, kasowaniem danych, płatnościami, zmianami produkcyjnymi. |