Agent Architecture Mental Model¶

Egy agentic application nem egyszerűen „egy LLM néhány toollal”. Olyan szoftverrendszer, amelyben egy probabilisztikus döntési komponens determinisztikus runtime-on belül működik, miközben a runtime tulajdonolja a state-et, policyt, executiont, persistence-et és observabilityt.

Hasznos kiinduló modell:

User / API / Event
        ↓
Application Use Case
        ↓
Agent Runtime / Orchestrator
        ↓
Context Builder → Model Gateway
        ↓                ↓
   state projection   decision proposal
                         ↓
              Policy / Validation Layer
                         ↓
             Skill / Tool / Workflow
                         ↓
                 External World
                         ↓
                    Observation
                         ↓
                  Runtime State

Az LLM tehát egy komponens a döntési útvonalban, nem az application tulajdonosa.

Model vs agent vs runtime¶

Ezeket a fogalmakat érdemes külön tartani:

Model
  probabilistic inference component

Agent
  goal-directed execution capability built around a model

Agent Runtime
  software that owns lifecycle, state, tools, policies, budgets and loop control

Application
  business/domain system that decides why the agent exists and what it may accomplish

Egy model tud szöveget generálni anélkül, hogy agent lenne. Agent azért létezik, mert egy runtime state-et, capabilityket és execution loopot ad köré. A tényleges business contract továbbra is az application felelőssége.

Probabilistic core, deterministic shell¶

A központi engineering pattern:

        deterministic shell
┌────────────────────────────────────┐
│ auth / policy / state / budgets    │
│ validation / retries / audit       │
│                                    │
│       probabilistic core           │
│      ┌──────────────────┐          │
│      │      LLM         │          │
│      │ plan / classify  │          │
│      │ decide / draft   │          │
│      └──────────────────┘          │
│                                    │
│ tool execution / persistence       │
└────────────────────────────────────┘

A modellt ott használd, ahol a semantic reasoning értéket ad:

ambiguous request értelmezése,
planning hiányos információból,
hasznos következő action kiválasztása,
információ összefoglalása vagy transzformálása,
jelentés kinyerése unstructured adatból,
több valid stratégia közötti választás.

A determinisztikus software feleljen a hard guarantee-kért:

authorization,
data integrity,
pénzmozgás,
permission check,
schema validation,
state transition,
idempotency,
resource budget,
approval gate,
audit logging,
cancellation és timeout enforcement.

A model ajánlhat SEND_REFUND actiont; az application code dönti el, hogy a caller jogosult-e, refundable-e az order, kell-e approval, és megtörtént-e már a művelet.

Control plane vs execution plane¶

Hasznos két fogalmi síkot megkülönböztetni.

Control plane¶

A control plane azt dönti el, mi történjen következőnek, milyen constraint-ek mellett.

Tipikus responsibilityk:

run creation,
goal és policy resolution,
context construction,
planning,
next-action selection,
routing skills/tools felé,
budget accounting,
stop-condition evaluation,
checkpointing.

Execution plane¶

Az execution plane tényleges műveleteket végez a rendszereken.

Példák:

GitHub repository olvasása,
SQL végrehajtása kontrollált data service-en keresztül,
email küldése,
fájl írása,
deployment API hívása,
search index lekérdezése.

Ehhez nem kell külön microservice. A distinction egy modular monolithon belül is létezhet. Először responsibility boundary, és csak másodsorban deployment boundary.

Canonical state a modellen kívül éljen¶

Production runtime ne támaszkodjon a conversation contextre canonical state store-ként.

Rossz mental model:

LLM conversation
      =
current truth about the run

Jobb:

State Store
   ↓
selected projection
   ↓
Model Context

A runtime state például tartalmazhatja:

run_id
status
goal
success_conditions
current_plan
completed_steps
pending_steps
observations
artifacts
budgets
approvals
tool_results
failure_history
state_version

A model csak a current decisionhöz releváns projectiont kapja.

Ez lehetővé teszi:

resumability,
concurrency control,
auditálhatóság,
replay/debugging,
context compaction,
model/provider cserét,
deterministic state transitionöket.

Fő architekturális boundaryk¶

Application boundary¶

A business use case-eket és domain rule-okat definiálja. Az agent nem lehet kerülőút az application service-ek körül.

Model boundary¶

A provider-specifikus viselkedés model gateway vagy port mögött legyen. Ne szóródjanak provider SDK callok a business module-okban.

Capability boundary¶

Tools és skills szűk, typed capabilityket expose-oljanak, ne raw infrastructure hozzáférést.

Preferáld:

create_support_ticket(input)

az ilyen helyett:

execute_arbitrary_http_request(url, method, body)

State boundary¶

A runtime tulajdonolja a durable execution state-et. Model context nem adatbázis.

Policy boundary¶

Authorization és safety rule-ok a model compliance-től függetlenül enforce-olhatók legyenek.

External-system boundary¶

Minden side effect adapteren menjen át, ahol timeout, retry, idempotency, credential és observability kontrollálható.

Failure boundaryk AI mellett¶

A hagyományos code/infrastructure failure mellé bekerül a semantic failure: a model syntactically valid, de rossz döntést hozhat.

Hasznos kategóriák:

Model failure
  invalid / low-quality decision

Contract failure
  schema or business validation fails

Policy failure
  action not authorized

Tool failure
  dependency unavailable / timeout

State conflict
  stale observation / optimistic lock conflict

Execution failure
  side effect partially or ambiguously completed

Ezek ne egyetlen generic agent failed exceptionbe essenek.

Először application, csak utána distributed system¶

Az AI nem jelenti automatikusan azt, hogy microservice architecture kell.

Erős kezdeti struktúra lehet:

Modular Monolith
├── domain modules
├── application/use cases
├── agent_runtime
├── skills
├── retrieval
├── policy
└── infrastructure adapters

A service extractionnek konkrét oka legyen:

independent scaling,
külön ownership,
erősebb isolation,
eltérő availability requirement,
special infrastructure,
independent deployment lifecycle,
security/tenant boundary.

Példa: support agent¶

HTTP API
  ↓
ResolveCustomerIssue Use Case
  ↓
Agent Runtime
  ├── Model Port
  ├── CustomerLookup Skill
  ├── OrderRead Skill
  ├── RefundProposal Skill
  └── TicketCreation Skill
          ↓
      Policy Layer
          ↓
Application Services
          ↓
CRM / Orders / Payments

Az agent reasoning alapján mondhatja, hogy refund indokolt. De nem kerüli meg a refund application service-t: ugyanaz a deterministic refund policy fut, mint normál UI/API útvonalon.

Anti-patternök¶

Az LLM maga az application¶

request → giant prompt → tool access → hope

Nincs explicit state, policy vagy use-case boundary.

Provider SDK mindenhol¶

Business code sok modulban közvetlenül importál egy model providert. Nehéz lesz tesztelni és cserélni.

Raw infrastructure toolként¶

A model generic shell/database/network hozzáférést kap, amikor domain-specific capability biztonságosabb lenne.

Hidden state a promptokban¶

Fontos execution state csak message-ekben vagy model-created note-okban létezik.

Agent megkerüli a domaint¶

A normál application path validál, az agent viszont közvetlen infrastruktúrát hív és kihagyja a rule-okat.

Gyakorlati design rule¶

Minden responsibilitynél kérdezd meg:

Semantic judgement kell, vagy guarantee?

Ha judgement kell, az LLM részt vehet benne.

Ha guarantee kell, deterministic software tulajdonolja.

Takeaways¶

A model nem az agent runtime.
Az agent runtime nem az egész application.
Probabilistic reasoning determinisztikus boundarykon belül működjön.
Canonical state a model contexten kívül legyen.
Legyen explicit application, model, capability, policy és state boundary.
Ne vezess be microservice-eket csak azért, mert AI van a rendszerben.
Az architecture fontosabbá válik, nem kevésbé fontossá, amikor a rendszer egy része probabilisztikus.