Single Agent, Workflow and Multi-Agent Patterns¶

Az agent topologyt a probléma control-flow uncertaintyje, responsibility boundaryja, permission boundaryja és scaling igénye alapján válaszd. A multi-agent nem olyan maturity level, amelyhez minden rendszernek el kell jutnia.

Hasznos default sorrend:

Deterministic code
      ↓ if semantic decision needed
Workflow with agentic step
      ↓ if task needs iterative autonomy
Single agent
      ↓ only with concrete separation need
Multi-agent

A legegyszerűbb topology, amely megtartja a szükséges behaviort, általában a legkönnyebben tesztelhető, secure és üzemeltethető.

Pattern 1: Deterministic workflow¶

Ha a process ismert, tartsd explicitnek.

validate request
   ↓
load customer
   ↓
calculate eligibility
   ↓
generate explanation
   ↓
send response

Lehet, hogy csak az explanation stephez kell LLM.

Előny:

predictable control flow,
egyszerű tracing,
explicit retry,
egyszerű permission,
alacsonyabb cost,
kevesebb failure mode.

Ne cserélj ismert application logicot agentre csak azért, mert modellel is meg lehetne csinálni.

Pattern 2: Deterministic workflow agentic islanddal¶

Ez gyakran erős production pattern.

Deterministic workflow
   │
   ├── deterministic step
   │
   ├── [agentic island]
   │      observe
   │      decide
   │      use tools
   │      verify
   │      stop
   │
   └── deterministic continuation

Az overall business process látható marad, miközben bounded részek semantic reasoningot használhatnak.

Incident példa:

create incident record
      ↓
collect known telemetry
      ↓
[agent investigates probable cause]
      ↓
human approves remediation
      ↓
deterministic remediation workflow
      ↓
close incident

Pattern 3: Single agent¶

Egy agent jó, ha egy koherens goal egyetlen policy/context/permission boundaryval megoldható.

Agent Runtime
├── skills
├── tools
├── retrieval
├── state
└── policy

A single agent belül továbbra is erősen modular lehet.

Ne keverd össze:

one agent

és:

one giant class / prompt / context

Jó fit¶

interactive research,
coding task egy repo/policy scope-ban,
troubleshooting,
document analysis,
bounded operational assistance.

Warning sign¶

Single agent nehézzé válik, ha incompatible:

permissions
trust levels
context scopes
models
ownership teams
latency/SLO profiles

keverednek benne. Ezek erősebb boundaryt indokolhatnak.

Pattern 4: Plan → execute¶

Ugyanaz a runtime előbb plant készít, majd végrehajtja:

Goal
 ↓
Plan
 ↓
Step 1
 ↓
Step 2
 ↓
replan if state changed
 ↓
complete

Több dependent stage esetén hasznos. Az initial plan hypothesis, nem truth.

Pattern 5: Planner / executor separation¶

Planner
   ↓ Plan / next objective
Executor
   ↓ Action result
Planner

Hasznos lehet, ha:

planninghez erősebb/slower model kell,
executionhöz cheap model is elég,
planner ne kapjon write credentialt,
plan külön evaluálandó,
execution nagyon constrained.

Ez nem jelenti automatikusan, hogy két independently deployed agent kell.

AgentRuntime
├── PlannerStrategy
└── ExecutorStrategy

Először logical separation, utána csak indokolt esetben distributed-system separation.

Pattern 6: Supervisor / workers¶

Supervisor bounded taskokat delegál:

Supervisor
├── Worker A
├── Worker B
└── Worker C

Worker indokolt lehet:

specialized context
specialized capabilities
separate permissions
parallel work
independent ownership

Példa:

Release Supervisor
├── Test Analysis Worker
├── Dependency Risk Worker
└── Documentation Worker

A supervisor structured resultokat kapjon, ne unlimited conversational transcriptet.

Worker contract¶

Handoff normál API contracthoz hasonlítson:

{
  "task_id": "task_88",
  "objective": "Analyze failing integration tests",
  "input_artifacts": ["artifact_12"],
  "constraints": {
    "read_only": true,
    "max_steps": 10
  },
  "expected_output": "TestFailureAnalysisV1"
}

Result is typed legyen.

Pattern 7: Specialist handoff¶

Néha valóban felelősségváltás történik:

General Support Agent
        ↓ handoff
Billing Specialist Agent

Külön agent indokolt lehet, ha a specialistnek más:

instruction,
data scope,
allowed tool,
compliance policy,
model/runtime config

kell.

Handoff explicit adja át:

objective
relevant state
approved context
artifact references
permissions scope
reason for handoff

Ne passzold automatikusan a teljes previous contextet, ha least privilege vagy relevance ellen szól.

Pattern 8: Fan-out / fan-in¶

Independent analysis parallelizálható:

           ┌→ Security analysis ─┐
Task ──────┼→ Performance review ├→ Aggregator
           └→ API compatibility ─┘

Csökkentheti latencyt és növelheti coverage-et, de emeli costot és error amplificationt. Fan-out legyen bounded.

Pattern 9: Event-driven agent run¶

Egyes taskok eventre ébredjenek, ne polling loopban maradjanak:

Run waits
   ↓
state = WAITING_FOR_EVENT
   ↓
external event arrives
   ↓
queue message
   ↓
worker reloads state
   ↓
continue

Példák:

CI completed,
human approved,
deployment finished,
new email arrived,
asynchronous analysis returned.

Mikor indokolt külön agent?¶

Jó teszt:

A boundary az „agent” szó nélkül is architecture szempontból értelmes lenne?

Jó ok:

separate business responsibility
separate permission boundary
separate trust boundary
independent scaling
independent ownership/deployment
materially different context/model policy
parallel independent workload

Gyenge ok:

"This prompt is long"
"Multi-agent sounds more advanced"
"We want agents to debate"
"Each function should be an agent"

Sokszor skill, module vagy deterministic service a jobb abstraction.

Multi-agent cost model¶

Minden plusz agent hozzáadhat:

model calls
context duplication
coordination messages
state synchronization
security boundaries
retry complexity
observability requirements
latency

Egy supervisor + 4 worker + follow-up + aggregator könnyen 10× drágább lehet egy jól instrumentált single agentnél.

Shared vs isolated state¶

Kerüld az unstructured global scratchpadot.

Preferáld:

canonical workflow/run state
        ↓
explicit task projection
        ↓
worker-local execution state
        ↓
structured result
        ↓
canonical state update

Ez csökkenti race conditiont és accidental context leakage-et.

Permissions¶

Minden worker csak a taskhoz szükséges capabilityket kapja:

Supervisor: may delegate
Security worker: repo read only
Deployment worker: deploy read + approved execute
Documentation worker: docs write only

Ne minden agent kapja az összes credential unionjét.

Partial failure¶

3 workers requested
2 succeeded
1 timed out

Policy lehet:

fail whole task
continue with partial evidence
retry one worker
use fallback worker
ask human

Infrastructure retry semantics ne a supervisor natural-language improvisationja legyen.

Gyakori anti-patternök¶

Agent every module.
Agents chatting freely explicit handoff/state nélkül.
Multi-agent baseline single-agent mérés előtt.
Shared unrestricted tool pool.
Planner mint unquestioned authority stale plan mellett.
Distributed agents pusztán logical separation miatt.
Handoff contract nélkül transcript dump.

Decision heuristic¶

Is control flow known?
 ├─ yes → deterministic workflow
 │          └─ semantic step needed? → agentic island
 │
 └─ no → does one coherent policy/context handle the task?
            ├─ yes → single agent
            └─ no → is there a real responsibility/permission/scaling boundary?
                       ├─ yes → multi-agent / worker pattern
                       └─ no → simplify

Engineering takeaways¶

Multi-agent architecture trade-off, nem upgrade path.
Deterministic workflow + bounded agentic island erős default.
Egy modular single agent jó, ha egy policy/context boundary elég.
Planner/executor először logikailag legyen külön, csak utána deploymentben.
Supervisor/worker között explicit typed handoff contract kell.
Separate agentet real responsibility, permission, trust, scaling vagy ownership boundary indokoljon.
Worker state legyen izolált, result structured módon menjen canonical state-be.
Mérd, hogy az extra agentek adnak-e elég qualityt a cost/latency/complexity árért.