Agentic AI engineering: tools, memory and verification

1. Why agentic AI now

Deck 12 (Aguzzi, "AI-Engineering: Tools, Agents and Verification") opens with a guiding question that structures the whole chapter: "how can a language model perceive, decide, act, remember, and remain verifiable?" The historical motivation is precise: "modern agentic AI emerges when classical agent (like reinforcement learning) theory meets foundation-model capabilities. Classical AI already gave us the vocabulary of agents, environments, actions, and goals — previous lessons on reinforcement learning and Markov decision processes introduced these concepts in a formal way :)" — the connection to chapter 13 is explicit on the first slide. "Modern LLMs add a practical interface: they can interpret natural-language tasks and coordinate multi-step workflows."

This creates three engineering questions, which map exactly onto the three parts of the chapter's title:

1. "how can an LLM become the reasoning core of an agent? (thinking model, planner, etc.)" — the agent itself;
2. "how can that agent interact with external systems?" — tools (and memory);
3. "how can we verify whether the resulting behavior is correct, safe, and reliable?" — verification.

The reference lens throughout is LangChain4j, "to discuss these ideas at the application level" — a Java/Scala framework whose abstractions (AI Services, tools, ChatMemory, agents, verification helpers) let the lecture talk about architecture instead of plumbing. The closing lesson of the deck, "power without verification is not engineering", is the same thesis that opened the course in chapter 1: validation is pervasive, and it applies to agents too.

2. Agent: working definition and core properties

The deck's working definition is deliberately classical:

"An agent is a system that perceives an environment, selects actions, and executes them in pursuit of explicit objectives."

Three terms carry the load: "perception provides information about the current state of the world (or of the task)"; "action modifies the environment, the system state, or the available knowledge"; "objectives define the criterion by which one action is preferred over another — in LLM-based agents, objectives are often expressed as natural-language instructions". The key point of the slide: "agency is defined by the full perception-action loop, not by intelligence alone" — a model that only generates text is not an agent; a model embedded in a loop that perceives, decides and acts is.

The four core properties tell us "what kind of system we are building":

• Situatedness — "the agent is embedded in an environment and can affect it";
• Autonomy — "the agent can choose actions without step-by-step human control; note: autonomy is a spectrum, not a binary property";
• Goal-directedness — "behavior is evaluated relative to explicit objectives";
• Temporality — "decisions unfold over time rather than in a single isolated step".

The RL echo is deliberate: the perception-action loop is the agent-environment interface of chapter 13, section 3, goal-directedness is the reward hypothesis, temporality is the episode. What changed is the reasoning core: where the RL agent learned a policy from rewards, the LLM agent interprets objectives in natural language and plans multi-step actions — and both face the same engineering problem of abstraction ("the number of states and actions reasonably limited") and of verification.

3. Building blocks and AI Services

"An agentic system works only when model, tools, memory, and orchestration remain aligned." The deck's architecture has four layers:

• Reasoning layer — LLM: "interprets the goal, plans candidate actions, and synthesizes answers";
• Action layer — Tools: "expose external capabilities such as search, APIs, databases, or code execution";
• Continuity layer — Memory: "preserves information across steps and across interactions";
• Control layer — Orchestration: "translates model outputs into executable operations and returns observations".

LangChain4j's first high-level abstraction above raw chat is the AI Service: "a declarative Java interface whose methods are implemented by an LLM-backed runtime". "The application invokes a method, while the framework handles prompt construction, model invocation, and result mapping"; "optional capabilities such as tools, memory, and retrieval can be attached to the same abstraction". The canonical example — a sentiment analyser with a typed boolean return:

trait SentimentAnalyzer:
  // The @UserMessage annotation specifies the prompt template for this method.
  @UserMessage(Array("Does {{it}} has a positive sentiment?"))
  def analyzeSentiment(text: String): Boolean

object SentimentAnalyzer:
  def createWith(llmModel: ChatModel): SentimentAnalyzer =
    AiServices.builder(classOf[SentimentAnalyzer])
      .chatModel(llmModel)
      .build()

def testSentimentAnalyzer(): Unit =
  val model = OllamaChatModel.builder().baseUrl("http://localhost:11434")
    .modelName("gemma4:e2b")
    .build()
  val sentimentAnalyzer = SentimentAnalyzer.createWith(model)
  sentimentAnalyzer.analyzeSentiment("Scala is a great programming language!") // true

Read it as an interface-driven design: the application declares what it wants (a function from String to Boolean) and the framework supplies how (prompt construction, model call, result mapping). This is the "declarative over procedural" spirit of the whole course — from the DSLs of chapter 9 to the aggregate programs of chapter 14.

4. Tools: contracts and function calling

"Tools turn language into action." A tool is "a callable resource outside the model, exposed through a well-defined interface" — "a tool is not stored inside the model parameters; it is made available by the surrounding software system". The minimum contract has four parts:

• name for identification — e.g. "WebSearch", "Calculator", "SQLQuery", "CodeExecutor", "SensorReader";
• description for semantic guidance — "use this to find recent information on the web";
• input schema for valid arguments — "a JSON schema that specifies required fields and types, with a clear format for the model to follow";
• output schema for interpretable results — "same as input schema, but for the tool's response".

Why tools matter: grounding — "tools can reduce hallucination by connecting answers to external information sources: before replying, the model can check facts, compute results, or query databases instead of relying solely on internal knowledge (self-augmentation and self-correction patterns)"; capability extension — "tools enable actions that plain text generation cannot perform reliably on its own (e.g. performing calculations, or manipulating structured data)"; system interaction — "tools let the agent read from and write to real systems"; observability — "tool schemas make behavior easier to inspect and evaluate".

"A good tool specification acts as a contract between the model and the execution layer... better tool contracts usually produce more reliable tool selection and safer execution." The LangChain4j calculator shows the pattern — @Tool annotations generate the JSON schema:

class Calculator:
  @Tool(name = "sum", value = Array("Calculate the sum of two numbers"))
  def sum(@P("left value") a: Double, b: Double): Double = a + b
  @Tool(name = "subtract", value = Array("Calculate the difference of two numbers"))
  def subtract(a: Double, b: Double): Double = a - b
  @Tool(name = "multiply", value = Array("Calculate the product of two numbers"))
  def multiply(a: Double, b: Double): Double = a * b
  @Tool(name = "divide", value = Array("Calculate the quotient of two numbers"))
  def divide(a: Double, b: Double): Double = a / b

trait MathAgent:
  @UserMessage(Array("I need to perform this calculation: {{expression}}"))
  def calculate(expression: String): Double

@main def testMathAgent(): Unit =
  val model = //...
  val mathAgent = AiServices.builder(classOf[MathAgent]).chatModel(model)
    .addTool(new Calculator).build()
  mathAgent.calculate("What is the sum of 5 and 7?") // 12.0

How does language become action? "The orchestration layer converts language into execution and execution back into context": the agentic system must "describe available tools to the model, interpret the model's action request, execute the selected tool, return the result as a new observation". The historical baseline was zero-shot tool use: "tools described directly in the prompt, the model asked to emit a textual pseudo-command — limitation: formatting errors became execution errors". Current practice: "many modern models already support this ReAct-style loop natively — they decide when a tool is needed, emit a structured request, observe the result, and continue reasoning". "Function calling is the usual interface: the model returns a typed function name with validated arguments instead of fragile free text"; "frameworks such as LangChain4j help normalize provider-specific tool-calling APIs at the application level".

Finally, the Model Context Protocol (MCP) addresses integration fragmentation: "traditional integrations (files, Slack, GitHub) require custom point-to-point glue code, leading to fragmentation and duplicate effort"; MCP is "a standardized open protocol to securely connect AI models to any data source or tool — build once, use everywhere". Architecture: "MCP Client: your AI application (e.g. LangChain4j) requesting tool execution; MCP Server: standalone process exposing dynamic schemas (e.g. read_file, write_file)"; "the client discovers tools dynamically at startup via a handshake; communicates via local processes (Stdio) or remote hosts (Streamable HTTP)". The deck's verdict: "conceptually it just a simple way to decouple the model's tool-calling interface from the actual implementation of tools."

5. Memory: short-term, long-term, and RAG

"Memory turns interaction into continuity": memory is "the mechanism by which an agent stores, retrieves, and reuses information across reasoning steps or across interactions". The first distinction of the lecture is Memory ≠ History: "History: a raw, passive, chronological transcript of what happened. Memory: an active, curated subset injected into the context to shape the reasoning process." The four pillars of memory: continuity (conversation context across turns and steps), personalization (user preferences, instructions, settings), planning (task state, subgoals, execution progress), retrieval (contextually injecting relevant prior or external knowledge).

The two lifecycles:

• Short-term memory (working / conversation state): "scope: limited to the current conversation or active task; mechanism: injected directly into the model's context window; purpose: maintains immediate execution state, goals, and recent turns; lifecycle: volatile — discarded or archived when the session ends". In LangChain4j the primary abstraction is ChatMemory, customisable with policies: eviction ("selectively dropping specific message types, e.g. redundant tool outputs"), compression ("summarizing older turns to preserve context while saving tokens"), filtering ("removing irrelevant or outdated intermediate reasoning steps"). A sliding window is one line: MessageWindowChatMemory.withMaxMessages(10). Multi-user isolation uses @MemoryId: "for concurrent users, memory must be isolated per session" — LangChain4j routes interactions to per-session memories via chatMemoryProvider(sessionId -> ...).
• Long-term memory (persistent knowledge): "scope: extends across multiple conversations and user interactions; mechanism: stored in external databases/vector stores and retrieved dynamically; purpose: remembers user preferences, historical patterns, and system instructions; lifecycle: durable — persists indefinitely and is continuously updated". Its typical implementation is RAG (Retrieval-Augmented Generation): "Retrieve: match the user's query against an external store (like a vector database); Augment: select the most relevant chunks and inject them into the context window; Generate: allow the model to reason and answer using this newly injected knowledge". Quality factors: "freshness of information, provenance (sources), and retrieval relevance".

RAG splits into two stages. Indexing (offline): "documents are cleaned, parsed, and split into smaller segments (chunking — cuts long texts into cohesive segments fitting the context window); each segment is converted into a numeric vector (embedding — text into numeric coordinates representing semantic concepts) and stored". In LangChain4j, FileSystemDocumentLoader.loadDocuments("/docs") + an in-memory EmbeddingStore + EmbeddingStoreIngestor handle "segment splitting, embedding generation, and database storage" automatically. Retrieval (online): "the query is vectorized using the same embedding model; a specialized vector store (Vector Store: database optimized for high-speed semantic similarity searches) finds and returns semantically similar segments; relevant segments are injected directly into the LLM prompt context" — in code, an EmbeddingStoreContentRetriever bound to the AI Service via contentRetriever(retriever) with maxResults(3). "For both stages, the choice of embedding model (semantic depth), chunking strategy (segment size), and vector store (retrieval architecture) directly determines retrieval precision and relevance."

6. Workflows and pure agents

With tools and memory in place, the question is orchestration. The deck uses Anthropic's taxonomy of two paradigms:

• Workflows: "orchestration of LLMs and tools via deterministic, hardcoded paths — structure: sequences, loops, parallel execution, and conditional branches; trade-offs: extremely predictable, highly reliable, easy to test, but rigid";
• Pure agents: "the LLM acts as an autonomous reasoning core and planner — structure: the agent dynamically decides which tool or subagent to call next based on state; trade-offs: high flexibility, extremely adaptive, handles unexpected edge cases, but harder to predict and verify".

The practical perspective: "start with workflows, introduce pure agency only for high-complexity, unstructured decisions".

In LangChain4j, an agent is "defined as an interface (similar to an AI Service)" with the @Agent annotation; subagents "can write results to a shared state and read input from previous steps". The AgenticScope is "a stateful blackboard containing data shared among the subagents participating in an agentic system": a shared blackboard ("agents read required inputs from the scope and write results back using outputKey"), an automatic registry ("automatically logs the exact sequence of agent invocations and their raw outputs" — the observability that verification needs), and persistence & recovery ("the scope can be serialized, persisted, and reloaded to recover a multi-turn process from failure"). "In practice: the scope decouples agent execution from orchestration routing."

The workflow builders cover the taxonomy:

• Sequential — "execute subagents one after another": AgenticServices.sequenceBuilder().subAgents(creativeWriter, audienceEditor).outputKey("editedStory").build();
• Loop — "iteratively refine output until a condition is met": loopBuilder().subAgents(styleScorer, styleEditor).maxIterations(5).exitCondition(scope => scope.readState("score", 0.0) >= 0.8);
• Parallel — "run independent agents concurrently": parallelBuilder().subAgents(foodExpert, movieExpert).executor(...) — with the safety note that "subagents in parallel mappers cannot have ChatMemory" (concurrency and shared mutable memory do not mix);
• Conditional — "execute different agents based on scope state": conditionalBuilder().subAgents(scope => scope.readState("category") == "MEDICAL", medicalExpert)...;
• Supervisor — the pure-agent end: "a Supervisor Agent uses an LLM planner to orchestrate subagents dynamically... instead of rigid routes, the supervisor determines the next agent to invoke based on context... it communicates via structured AgentInvocation requests and observes outcomes in a loop". The bank example: supervisorBuilder().chatModel(plannerModel).subAgents(withdrawAgent, creditAgent, exchangeAgent).responseStrategy(SupervisorResponseStrategy.SUMMARY) — "Transfer 100 EUR from Mario to Georgios". Response strategies: LAST ("the response of the last executed subagent", default), SUMMARY ("the supervisor's transactional summary of operations"), SCORED ("an LLM scorer chooses the best response between the two"). Context policies guide the planner: supervisorContext("Policies: Prefer internal tools, currency is USD"), overridable per invocation.

7. Verification: the three-stage evaluation loop

"Power without verification is not engineering." Why traditional assertions fail: "agent loops are multi-step, stateful, and non-deterministic"; "unit testing assumes deterministic, reproducible state-to-state mappings"; "models behave as black-boxes with probabilistic output spaces"; "small changes in prompts can cause catastrophic, silent regressions"; "dialogue histories and intermediate tool responses create an infinite state space"; and "error propagation (cascading failures): a minor reasoning or tool-call error in step i propagates and amplifies through subsequent steps". The conclusion: "we must evaluate the entire trace of the interaction, not just the final output".

The deck's answer is a 3-stage evaluation loop running "continuously at different granularities and speeds":

• Level 1 — Unit Tests & Assertions (Deterministic Filter): "programmatic, zero-LLM checks run on every code change (CI/CD pipeline); ensures compliance with JSON schemas, regex constraints, and system-level latency bounds". The metric is pass@k: "the fraction of problems solved when generating k candidate solutions — a problem is considered solved if at least one sample passes verification". The unbiased estimator: "rather than drawing k samples directly (high variance), we generate n samples (n ≥ k), count successful candidates c passing verification, and use pass@k = E[1 − C(n−c,k)/C(n,k)]". Generalisation: "an LLM-as-a-Judge can act as the automated validator to compute pass@k on semantic or free-text generation". The temperature trade-off: "for pass@1, use low temperature (0.0–0.2) to minimize bad paths; for high k (e.g. pass@10), use high temperature (0.7+) to maximize sample diversity, increasing the probability that at least one candidate passes".
• Level 2 — Model & Human-in-the-Loop (Semantic Validation): evaluation "of semantic correctness and multi-step reasoning against a curated Golden Dataset — a highly curated, diverse dataset of 20–100 high-value test cases reviewed and validated by domain experts to represent the system's operational envelope". Dimensions: core capabilities (tool calling, reasoning, routing), user diversity (skill levels, writing style, formatting), edge scenarios (adversarial queries, out-of-distribution inputs, system prompt attacks); and the dataset is a living asset — "as new failure modes are uncovered in production (Level 3), they are distilled and backported". Critique shadowing with domain experts: "1–5 numerical ratings suffer from extreme cognitive bias and low Cohen's Kappa"; instead ask only binary judgments ("Is this output ready for production?") and require "a concise, one-sentence critique explaining the specific reason (e.g. 'Over-promised refund without checking order state')" — "human-written critiques provide the precise, qualitative instructions and few-shot examples needed to align your automated LLM judge". LLM-as-a-Judge: "critique-first prompting" ("asking an LLM for a binary verdict directly leads to high false-positive rates; force the model to write the critique first — Chain of Thought reasoning — and only then output PASS/FAIL"), "few-shot real alignment" (inject human-annotated critiques into the system prompt), "human-to-model agreement KPI" (run the judge on the Golden Dataset, measure agreement, reconcile gaps), and "deconstruction of complex rubrics" into "a cascade of independent, specialized, binary judges (e.g. Tone, Accuracy, Policy Compliance)". RAG evaluation — the RAGAs triad: "Faithfulness (Groundedness): are the generated claims supported only by the retrieved context? (Answer vs Context); Answer Relevance: does the answer directly resolve the query? (Answer vs Query); Context Recall & Precision: did the retriever miss critical information? (Context vs Ground Truth) and did it fetch irrelevant context? (Context vs Query)".
• Level 3 — Production Telemetry & Monitoring (Statistical Safety): "real-world validation via continuous tracking of live user interactions; monitors implicit feedback, tool exception rates, model drift, and semantic divergence". Trace instrumentation (OpenTelemetry-native): "spans must capture the hierarchical, nested nature of agent loops — tracing flow: User Query → Planning Node → Sub-Agent Spawn → Tool Execution → Observation → Generation"; tooling: LangSmith, Langfuse, Arize Phoenix. Low-level execution logging (e.g. ChatModelListener): "precise context — raw prompts, system instructions, token counts, cost, temperature, latency — and aggregated low-level performance KPIs". Production telemetry analysis: exception rates ("monitor tool/API errors to catch breaking changes in external systems"), semantic drift ("flag incoming queries deviating from the evaluation Golden Set"), trace filtering ("surface high-latency traces and negative user feedback for manual curation").

Verifying the trajectory — "in multi-step agents, the path taken is as important as the final answer": tool selection accuracy (classification metrics Precision, Recall, F1 comparing expected vs actual tool-call traces); argument boundary checking ("validates that arguments emitted by the model fall within safe, expected ranges and schemas — preventing SQL/command injection"); observation grounding ("is the agent's next reasoning step logically coherent with the tool's output, or does it ignore facts/hallucinate past them?"); exception recovery (self-correction) ("inject simulated tool exceptions — API timeouts, rate limits — to verify if the agent's planner gracefully recovers, falls back to other tools, or reports failure cleanly"). The closing reminder: "a correct answer reached through an inefficient or unsafe tool loop is still an engineering failure."

8. The whole arc: closing the course

This is the last chapter, and the deck's own conclusion points beyond itself: "evaluating multi-step reasoning requires accounting for stochasticity, non-determinism, and complex tool trajectories"; "key dimensions for real-world deployment: model versioning (track behavioral changes over time to establish robust LLMOps pipelines), advanced observability (trace analysis tools like LangSmith), robust verification (simulation environments, synthetic datasets, and adversarial testing)". The frameworks it names — LangSmith, MCP, A2A (agent-to-agent communication) — are where the field is going.

Standing at the end of the course, the four parts assemble into one argument:

• Part A — Validate (chapters 1–5): the thesis that validation is pervasive — testing at every level, acceptance and integration testing, LLMs in the development process. Chapter 15's verification discipline is chapter 2's BDD/ATDD mindset applied to agents, and chapter 4's LLM evaluation recurs as LLM-as-a-Judge.
• Part B — Specify (chapters 6–8): Scala as the language in which models are written — ADTs, type classes, monads, effect systems. The QRL toolkit of chapter 13 and the ScaFi DSL of chapter 14 are this discipline in action: types everywhere, effects contained.
• Part C — Model (chapters 9–12): transition systems and Petri Nets, DTMC/CTMC, temporal logics and model checking, and finally simulation with kinetic Monte Carlo and Alchemist. The stairway of chapter 11 — simulation, approximate model checking, exact model checking — is the quantitative backbone on which both learning (chapter 13) and the verification of chapters 15's agents (simulation environments, ε, δ reasoning) rest.
• Part D — Learn and spread (chapters 13–15): RL from MDP to deep and multi-agent RL; aggregate computing as the purely functional programming of fields; agentic AI engineering as the LLM-based layer. The three chapters are one story: RL learns policies (what to do), aggregate computing deploys them as fields (where to do it), and agents orchestrate them with tools and memory (who decides, and how to verify).

The explicit bridges built along the way: Alchemist as the simulator of both chemical systems and aggregate programs (chapters 12 → 14); Q-learning learning policies inside simulations and for device parameters (chapters 12, 13 → 14); the reward hypothesis of chapter 13 as the goal-directedness of chapter 15's agents; the MDP vocabulary of chapter 13 as the formal grounding of the agent definition of this chapter; and the pervasive-validation thread from chapter 1, through model checking in chapter 11, to pass@k and LLM-as-a-judge here. One thread throughout, as the course index promised: rigorous specification, then pervasive validation of it.

9. Lab: operational steps and R&D directions

The lab deck (12-Lab) sums up: "agents: autonomous entities that perceive their environment, make decisions, and act to achieve goals; in the generative AI era, agents leverage LLMs/SLMs for reasoning and planning — tools: enable agents to interact with the external world (e.g. APIs, databases, and files); memory: stores short-term conversation context or long-term facts; coordination: complex tasks can be split across multiple specialized sub-agents. Verification and monitoring of agents: why? to ensure reliability, safety, correctness, and alignment with user intent; how? by evaluating tool traces, analyzing LLM reasoning (thought paths), and using programmatic assertions or other LLMs as judges; human-in-the-loop: monitoring execution loops to support user validation and feedback."

Operational steps

• Step 0 — environment setup. Clone the lab repository (asmd-public-12-agentic-ai-code, powered by LangChain4j and langchain4j-agentic) and import it in IntelliJ as an SBT project. Install and run Ollama locally: pull a reasoning model (ollama pull qwen3.5:4b or gemma4:e2b) and an embedding model (ollama pull ibm/granite-embedding:30m).
• Step 1 — AI Services and tools. In it.unibo.services, study SentimentAnalyzer and TicTacToe ("how they are defined as tools and used in the AiServices configuration"); in it.unibo.tools, study MathModule and ToolsViaZeroShot — how methods annotated with @Tool are registered and selected by the LLM/SLM.
• Step 2 — memory and RAG. In it.unibo.memory, study MemoryExample (conversational context) and RagExample (document ingestion, in-memory vector storage, semantic search retrieval).
• Step 3 — orchestration, workflows and evaluation. In it.unibo.agents, study multi-agent orchestration, state sharing via AgenticScope, and the strongly typed workflows (Sequential, Loop, Parallel, Conditional, Supervisor); in it.unibo.verification, study Evaluator — "how an LLM-as-a-Judge evaluates model correctness and computes the unbiased pass@k metric using Google Gemini".

R&D tasks

Test your knowledge