Анатомия AI-агента для сеньоров — pipeline, цикл, tools, ловушки

Key technological concepts (AI agents “anatomy”)

• Frameworks change fast, but the core architecture is similar. Weekly new agent frameworks are released (e.g., LangChain, AutoGen, Open Agent SDK, Google ADK, etc.), each claiming “build in 5 minutes.” However, the real challenges emerge in engineering and production behavior, not in the model itself.

• Agent vs workflow (automation spectrum):

  • Workflow systems: predefined steps/paths; the developer decides the step order, and the LM executes them.
  • Agents: the LM decides next actions and can select tools; this adds autonomy and unpredictability.

• Industry guidance (Anthropic / Human Layer / Gartner-style analysis): Start simple (workflow patterns), and only increase autonomy when needed.

Practical production evidence / failure modes mentioned

• Prototype → production scaling cost blowups: A $50 prototype later reached $2.5M/month when moved to production workload (example attributed to “agent scaling analysis”).

• Repeated refusal-to-stop / runaway loops: An agent ignored stop commands and produced the same answer 58 times in a row.

• Dangerous tool use causing “destruction”: An agent unpacked production configs and executed a destructive operation, removing core infrastructure. Recovery was possible via hidden snapshots.

• Gartner forecast: By 2027, 40%+ of agent projects will be closed due to uncontrolled costs, unclear business value, insufficient control, and risks.

• Core thesis: Models (GPT/CoT/Gemini) are capable—production engineering is the differentiator.

Pipeline: the “conveyor belt” inside any agent

Every request flows through stages that build a context window for the LM. The pipeline is designed around:

• Fast checks first, expensive model calls last (“block early, spend late”).
• Accumulation: each stage adds data; it doesn’t remove.
• Fail-safety: context must be serializable/sterilizable so a request can be recovered after crashes/timeouts.
• Separation of responsibilities: avoid coupling (e.g., security vs formatting/injection parsing).

Example stage list for a request (“Boris, I want coffee”)

1. Validation (cheap): reject empty/garbage/unsupported inputs to avoid wasting downstream costs.
2. Entry security: detect prompt injection attempting to force system prompt leakage or unauthorized actions.
3. Query enrichment: add task context (e.g., “Retro in an hour” merges into a concrete time-based task).
4. Memory / knowledge retrieval:
   • user preferences/history (memory)
   • subject knowledge (menus, promos, rules, runbooks, FAQ, etc.)
5. Content filtering: verify retrieved docs aren’t empty and don’t contain malicious/injected content.
6. Preparation / context assembly:
   • combine system prompt + retrieved knowledge + memory + chat history
   • manage token budget (trim history via “leave last,” summarization, compaction)
7. Model routing / model selection:
   • small fast classifier to choose the right chain and/or appropriate model complexity
   • optionally choose a “thinking” mode vs a cheaper mode
8. Generation (agent loop may occur here):
   • workflow: typically one pass
   • agent: the LM may call tools repeatedly in a loop
9. Exit security / output checks:
   • ensure no sensitive data leakage
   • validate output format (e.g., strict JSON/GSON validation)

Important note on workflow vs agent loops

• Workflow: loops can exist inside stages, but the developer-controlled code decides when to return.
• Agent: the LM decides whether more tool calls are needed (the classic agent loop).

The Agent Loop (“heart of the system”)

When autonomy is required, the agent runs a loop:

1. LM decides whether to call a tool
2. Tool executes
3. Tool result is appended to context
4. Loop repeats until the LM decides to answer

The talk emphasizes that the loop is where production systems break.

Why agent loops are dangerous (three main failure groups)

• Loss of control: agent fails to stop (e.g., 58 repeated answers).
• Money: each iteration costs model calls and often re-pays for the full context.
• Correctness: hallucinations compound—bad assumptions become “facts” for later tool calls/decisions.

Loop safeguards / “limiters” (must be in code, not just prompt)

Recommended hard constraints include:

• Iteration limit (task-dependent; e.g., ~25 for code agents, ~5 for support).
• Token budget limit across the whole loop.
• Tool call limit (e.g., avoid repeatedly calling the same “weather” tool).
• Human-in-the-loop confirmation when risk is detected:
  • irreversible actions: ordering, payments, deletion
• Abnormal parameter checks:
  • quantities too high, unexpected costs, suspicious budgets, etc.

If limiters trigger: what to tell the model

• Don’t respond with vague “Error.”
• Provide specific, instruction-like limiter context (what happened, remaining budget, what to do next) so the model can adapt rather than retry blindly.

If the agent stops anyway

• Partial result: return what succeeded.
• Escalation: handoff to human/operator.
• Repeat with different parameters: different model, truncated context, simplified request.

Tools: the “hands” of an agent

• An agent without tools is essentially a chatbot.
• Tool design is often more important than model choice.

Tool counts scale poorly

• Up to ~20 tools: manageable
• 20–50: tool interactions blur boundaries

• 50: “death by a thousand instructions” (model drowns in descriptions)

Good tool descriptions (model-readable “API contracts”)

• Name: verb + noun; clear purpose (avoid vague “helper”).
• Description: what it does; when to call it; prerequisites/conditions.
• Call policy: sometimes require human confirmation.
• Parameters: strict schema (types, bounds, pitfalls); defaults for optional fields.
• Response: structured JSON output schema.
• Errors:
  • tools should return model-understandable errors (e.g., budget exceeded + suggested next action)
  • avoid “dead-end” errors that lead to hallucinated retries

Tool connectivity and MCP caveat

• Tools can be wrapped via MCP (Model Context Protocol) servers, but the warning is:
  • automatic wrappers often handle the “happy path”
  • production must handle timeouts, empty responses, invalid data, partial results, long traces

Rule: before wrapping a service in MCP, enumerate errors and create specific model-understandable fallback behaviors.

Observability (not just logging)

The talk emphasizes: build observability from day one.

Track pipeline events and costs, including:

• stage start/end, errors
• tool invocations
• loop iteration counts
• model selection decisions
• cost and latency attribution

Motivation: without it, post-incident debugging becomes guesswork.

Context window and cost optimization (KV cache / “K/V cache hit rate”)

• Loop iterations can repeatedly re-process large contexts, driving costs up.
• Mitigation: K/V cache where the provider can reuse cached prefix computations.
• Major reason caches get invalidated:
  • inserting current time in the system prompt (changes every second → cache invalid)
  • mutating the middle of context (changes later tokens → must recompute)
  • JSON key ordering differences can break cache hits

Practical rules

• Treat context assembly like controlled “assembly” (choose/compress/select).
• During loop iterations, only append to the end to preserve cacheability.
• KV cache hit rate is described as a crucial production-economics metric.

Main speakers / sources (as referenced in the subtitles)

• Speaker: the video narrator/presenter (“I”, giving a synthesized model; introduces “we will do today” and the “Boris’s agent / Barista” examples).

• Industry sources cited:

  • Gartner: forecast about 40%+ agent project closures by 2027
  • Anthropic: guidance to prefer simple composable patterns; pipeline concepts; tool design emphasis; also mentioned “key thing back in 24”
  • Human Layer / Dex: 12 factors of agents methodology; interviewed founders

• Standards / protocols mentioned:

  • MCP (Model Context Protocol)