What Agentic Engineers Build
Six recurring system types — assistants, RAG, tool-calling systems, process automation, multi-agent systems, and the evaluation/observability layer that makes the others shippable.
The job, concretely
Agentic engineering is ordinary backend engineering with one new component: a probabilistic function that chooses actions. The job is to place that function where it adds value, surround it with deterministic code, and measure it continuously. The systems below recur across companies; most products combine two or three.
For each system type the key decisions are listed with the module that covers them. Notice how often the decision is "how little autonomy can I get away with?".
Assistants and RAG systems
AI assistants are conversational interfaces over knowledge and actions: support bots, coding assistants, internal "ask the company" tools. They look simple and are hard, because the user can ask anything and the acceptable failure rate is low. Key decisions: what the assistant knows (RAG or not), what it can do (tools or read-only), how risky its actions are (approval gates), and the latency budget. Detail in AI Assistants.
RAG systems answer from your documents instead of the model's weights. The pipeline is ingest → chunk → embed → store → retrieve → rerank → assemble context → generate → cite. Key decisions: chunk size and overlap, dense vs sparse vs hybrid retrieval, metadata filters, reranking, and how to evaluate retrieval separately from generation. Start at RAG Overview and RAG Evaluation.
- Assistant hard parts: grounding, refusal behaviour, tool safety, and consistent tone across thousands of conversations.
- RAG hard parts: retrieval recall on real queries, stale indexes, and citations that point at the wrong passage — see Citations.
Tool-calling systems and business process automation
Tool-calling systems let a model invoke functions with validated arguments: booking, querying, ticket updates, code execution. The model is a planner over an API surface you design. Key decisions: schema design, argument validation, error handling and retries, idempotency for side effects, and least-privilege permissions per tool. See Tool Calling Basics, Tool Schemas, Idempotency.
Business process automation chains tools across systems: read a document, extract fields, look up a record, update a database, request approval, notify. Key decisions: workflow engine vs agent, where humans approve, idempotent side effects, and an audit trail that survives a lawsuit. Detail in Business Process Automation and Workflow State Graph.
- Tool-calling hard parts: models pass plausible-but-wrong arguments; validate everything before execution — see Argument Validation.
- Automation hard parts: partial failure halfway through a multi-system write; design for resumability.
Multi-agent systems
When one agent's context or tool set gets too large, work is split across agents: a supervisor delegating to specialists, a pipeline of stages, a hierarchy, or a swarm. Key decisions: is this actually needed (usually not yet), how agents communicate, who owns shared state, and how failures propagate. See Multi-Agent Systems Overview and, first, When Not to Use Multi-Agent.
Multi-agent is where cost and debugging difficulty compound. A supervisor that re-sends full context to five specialists multiplies tokens by six and turns one trace into a tree. Build it when a single agent measurably fails, not because the diagram looks impressive.
- Hard parts: supervisor bottlenecks, duplicated work, inconsistent state, and traces nobody can read.
- The best multi-agent design is often one agent plus a deterministic router — see Router Architecture.
Evaluation and observability
The layer that turns the systems above from demos into products. Evals are test suites for probabilistic behaviour: golden datasets, deterministic checks (did the tool get called with the right id?), LLM-as-judge for open-ended quality, and regression runs on every prompt change. Observability is traces with spans per model call and tool call, carrying tokens, latency, cost and errors.
Key decisions: which metrics represent user value, how large a golden set is enough (often 50–200 well-chosen cases beat 5,000 random ones), how to keep judges honest, and what to alert on in production. See Evaluating Agents: Testing Probabilistic Systems, Eval Metrics: What to Measure and How, Tracing Agents and Logging, Metrics and Alerts.
- Every other system type is unshippable without this one: "it worked in the demo" is not evidence.
- Hard parts: flaky judges, datasets that drift from real traffic, and alerts that fire on cost only after the month closes.
Key points
- Six recurring builds: assistants, RAG systems, tool-calling systems, process automation, multi-agent systems, evals and observability.
- The recurring design question is how little autonomy the task needs, not how much the model can handle.
- RAG and tool calling are the two primitives; assistants and automation are compositions of them.
- Multi-agent is a scaling response to measured single-agent failure, not a starting point.
- Evals and traces are not optional add-ons; they are the layer that makes the other five shippable.
When to use — and when not to
- Orienting in a new project: identify which of the six you are building and load the matching module.
- Planning a roadmap: build the primitive (RAG or tools) before the composition (assistant, automation).
- Scoping a team: each system type maps to a distinct set of skills and failure modes.
- As a checklist of things every product must have — most products need two of the six.
- To justify multi-agent before a single agent has been measured.
- When the requirement is deterministic; then it is regular software with no LLM at all.
Failure modes
- Building an assistant without RAG or tools and expecting it to know company facts.
- Building a RAG system and never evaluating retrieval separately from generation.
- Shipping automation with side effects but no idempotency, then re-running a failed batch.
- Starting with a supervisor and five specialists for a task one agent with three tools would do.
- Treating evals as a launch-week task rather than a per-change gate.