Agentic Engineering

This area builds on AI Foundations and covers systems where an LLM can use reusable capabilities, act on external systems, observe results, maintain durable execution state and participate in controlled multi-step execution.

Learning areas

• Agent Skills — reusable capability contracts. First-draft complete.
• Agentic Loops — iterative observe/decide/act execution with planning, state, budgets, recovery, verification and human gates. First-draft complete.
• Agent Architecture — production software architecture around model, skills, loops, state, memory, tools, retrieval, policy, reliability, security and observability. First-draft complete.

Recommended learning order

1. Agent Skills ✅
2. Agentic Loops ✅
3. Agent Architecture ✅

Capability
   ↓
Agent Skill
   ↓
Agentic Loop
   ↓
Agent Runtime / Software Architecture

Core mental model

The complete workstream converges on:

probabilistic semantic decisions
          inside
explicit deterministic software boundaries

A production agentic system can be viewed as:

User / API / Event
        ↓
Application Use Case
        ↓
Durable Agent Runtime
  ├── canonical state
  ├── context builder
  ├── policy / authorization
  ├── budgets / recovery
  ├── skills
  ├── capabilities
  └── observability
        ↓
Application Ports
        ↓
Infrastructure Adapters
  ├── LLMs
  ├── retrieval/vector/search
  ├── MCP/connectors
  ├── databases
  ├── queues
  ├── sandboxes
  └── external APIs

The model can interpret, plan and propose next actions. The runtime/application remain responsible for canonical state, authorization, side-effect safety, hard completion checks, budgets, retry/idempotency, approval and lifecycle.

Software-engineering stance

Agentic applications are not exempt from normal architecture principles. Modular boundaries, dependency inversion, state ownership, authorization, observability and failure isolation become more important when probabilistic components are added.

The architecture material explicitly covers:

• modular monoliths,
• Hexagonal / Ports & Adapters,
• Clean Architecture,
• DDD-style bounded contexts,
• queues and asynchronous/event-driven boundaries,
• service extraction criteria,
• agent runtime/orchestrator responsibilities,
• context/tool/skill/state/memory/retrieval architecture,
• security and trust boundaries,
• single-agent vs workflow vs multi-agent topologies,
• production reliability/scaling,
• evaluation and observability.

A strong default is to organize around business capabilities rather than AI vendors/frameworks.

Business capability
      ↓
Application port
      ↓
AI / retrieval / MCP / provider adapter

Control-flow stance

Prefer the simplest architecture that solves the problem:

Deterministic code
      ↓ if semantic reasoning is useful
Workflow + agentic island
      ↓ if iterative autonomy is useful
Single modular agent
      ↓ only with a concrete separation reason
Multi-agent

Multi-agent is a trade-off, not an automatic target state.

State and context stance

operational/domain truth
        ↓
canonical run state
        ↓
session + intentional memory
        ↓
purpose-specific context
        ↓
model

Context and chat history should never silently become the hidden execution-state store.

Relationship to other AI areas

RAG, MCP and Memory remain useful separate deep-dive areas even though the Architecture workstream already defines where they connect.

• RAG can deepen ingestion, indexing, retrieval, reranking and evaluation.
• MCP can deepen protocol/runtime/server/client/tool/resource design and operational concerns.
• Memory can deepen long-term memory models, extraction, consolidation, retrieval, privacy and evaluation.

Completion state

Agentic Engineering is complete at first-draft depth. Future updates should primarily refine the chapters through questions, code exercises, implementation experience and production/evaluation lessons.

Next step

Review the material while studying it, then choose the next separate AI workstream deliberately from RAG, MCP or Memory.