Agent AI jest kontrolowaną pętlą decyzyjną
Produkcyjny agent jest użyteczny wtedy, gdy software musi zinterpretować cel, sprawdzić aktualny stan, wybrać spośród zatwierdzonych operacji i kontynuować do osiągnięcia ograniczonego outcome. Kluczowe jest słowo ograniczonego. Agent nie powinien dziedziczyć pełnego dostępu do aplikacji tylko dlatego, że model obsługuje tool calling.
Traktujemy model jako planner wewnątrz execution system. Identity, tenant context, authorization, business invariants, budgets, approval requirements i audit pozostają deterministycznymi kontrolami produktu poza promptem.
Wybierz najmniejszy poziom autonomii, który rozwiązuje problem
| Pattern | Swoboda modelu | Dobre zastosowanie | Wymagana kontrola |
|---|---|---|---|
| Model step | Jedna generacja/klasyfikacja | Summary, extraction, drafting | Schema i content validation |
| AI-assisted workflow | Wybór w stałej sekwencji | Triage, routing, recommendations | Deterministic workflow state |
| Bounded agent | Iteracyjny wybór tools | Research, multi-step operations | Tool allow-list, budgets, stop conditions |
| Approval-gated agent | Plan consequential action | Publishing, payments, account changes | Durable human approval przed side effect |
Wiele produktów nazywanych „agentic” jest bezpieczniejszych i łatwiejszych operacyjnie jako AI-assisted workflow. Iterację warto stosować tylko wtedy, gdy dynamic planning daje realną przewagę.
Zakres toola jest ważniejszy niż sformułowanie promptu
Tool jest kontraktem API, nie natural-language permission. Preferujemy wąskie domain commands, np. createDraftProposal, requestRefundReview czy scheduleFollowUp, zamiast ogólnego dostępu do bazy, shell lub admina. Każda komenda po stronie serwera waliduje actor, tenant, resource ownership, argumenty i current state.
Model może zaproponować akcję. Nie powinien móc redefiniować tego, czy akcja jest dozwolona. Dzięki temu authorization pozostaje testowalne mimo zmian promptu, modelu czy strategii reasoning.
Policy trzymaj poza modelem
Krytyczne reguły należą do kodu i danych: które roles mogą wywołać tool, jakie obiekty są dostępne, limity transakcji, maksymalna liczba iteracji, wymagane klasy approval, dozwolone destinations i stop conditions. Prompt instructions są wartościowym kontekstem, ale nie są enforcement boundary.
Takie rozdzielenie zwiększa także portability. Upgrade modelu nie wymaga ponownego udowadniania całego permission model, ponieważ te same server-side policies nadal ograniczają każde wywołanie.
Human-in-the-loop wymaga durable workflow state
Produkcyjny approval step nie może być chwilowym modalem, który znika po timeout requestu. Zapisujemy proposed action, evidence, actor, policy reason, current resource version i approval decision. Po decyzji człowieka ponownie walidujemy aktualny stan przed execution, ponieważ obiekt mógł w międzyczasie się zmienić.
Human review warto rezerwować dla consequential lub ambiguous steps. Jeśli każda niskiego ryzyka operacja wymaga approval, agent zwiększa latency bez realnego zmniejszenia pracy. Risk tiers pozwalają automatyzować odwracalne reads i drafts, a blokować irreversible writes.
Retries wymagają idempotency i execution budgets
Agent loops naturalnie ponawiają działania. Sieć zawodzi, model call ma timeout, a tool result może nadejść po utracie połączenia przez orchestrator. Write operations potrzebują więc idempotency keys lub równoważnych domain guards. Sam run powinien mieć limity czasu, tool calls, tokenów/kosztu i powtarzanych identycznych działań.
Dobry stop policy wykrywa pętle, np. ten sam failing tool wywoływany z tymi samymi argumentami. Zamiast dalej „reasonować”, orchestrator powinien przejść do repair, escalation lub terminal state z jednoznaczną przyczyną.
Memory jest kontekstem, a nie source of truth
Długotrwała pamięć agenta może poprawiać continuity, ale permissions, orders, invoices, bookings i customer records nadal trzeba odczytywać z authoritative systems. Memory przechowujemy z provenance i scope. Zapamiętana preferencja jest czymś innym niż aktualny entitlement czy zweryfikowane saldo.
W multi-tenant software retrieval pamięci musi podlegać tym samym granicom tenant/resource co zwykłe zapytania aplikacji. Semantycznie trafny chunk nie jest automatycznie autoryzowanym kontekstem.
Oceniaj trajectory, nie tylko końcowy tekst
Jakość agentów trzeba testować na całym execution trace: czy wybrano właściwy tool, uniknięto forbidden tools, poproszono o approval na poprawnej granicy, odzyskano kontrolę po awarii dependency, zatrzymano run w budżecie i osiągnięto poprawny final business state.
Tak podchodzimy w Softech do produkcyjnej automatyzacji AI i AI assistants: produktem jest kontrolowana ścieżka od intent do outcome wraz z dowodem, że system pozostał w swoim operating envelope.
Checklist produkcyjny
- Określ minimalny poziom autonomii potrzebny do zadania.
- Udostępniaj wąskie domain tools, nie szeroki admin access.
- Rozwiązuj authorization i tenant context poza modelem.
- Utrwalaj approvals i ponownie waliduj stan przed execution.
- Zapewnij retry-safety dla side-effecting tools.
- Ustal run budgets i loop detection.
- Scope’uj memory według tenant, resource i provenance.
- Oceniaj tool trajectories, policy compliance i final domain state.