CODE FARM
Galaxy background

"War is peace. Freedom is slavery. Ignorance is strength."

- George Orwell, 1984

Language Models and Agents

25 Jan 2026

The field of artificial intelligence is evolving rapidly, with innovation shifting large language models from text predictors into intelligent agents that interact with external systems.

1. Large Language Models

A Large Language Model (LLM) is a neural network (typically Transformer-based) trained on large-scale data that works mainly by predicting the next element in a sequence. Although originally text-focused, many of these models are now multimodal and can understand and generate text, images, audio, and video, supporting uses from text generation to image and multimodal question-answering. [1] [2] [3]

However, inherent limitations persist: models lack real-time information, cannot perform real-world actions, and their knowledge is fixed at training time.

  • Open-weight models (like LLaMA, Mistral, or Gemma) commonly use postfixes to signal how a shared base model was fine-tuned and what it is optimized for.

    • An -instruct postfix indicates a variant optimized for single-turn, structured outputs and reliable task-following, often with enhanced helpful/harmless behavior.

    • A -chat postfix indicates a dialogue-optimized variant intended for multi-turn conversations using a specific chat template.

    • A -tools postfix indicates a variant tuned to use external tools and to output structured tool_calls, a key capability for building agentic (ReAct-like) workflows.

    • A -thinking postfix indicates a variant optimized for complex, multi-step reasoning and is particularly well-suited for Chain-of-Thought (CoT) prompting techniques.

  • In contrast, many managed API providers (like OpenAI, Anthropic, and Google) increasingly provide a single front-door model name (e.g., gpt-4o) and control its behavior through the API request’s structure and parameters.

    • Instruction-following is default with chat-structured APIs using system/user/assistant roles.

    • Tool use is enabled by declaring tool definitions in the API request for the model to choose between text responses or a tool call.

    • Enhanced reasoning is controlled by request-specific settings, product tiers, or internal routing, not by selecting a distinct -thinking model.

1.1. Transformer

A transformer is a neural network architecture composed of an encoder and a decoder that processes token sequences via attention and feed-forward layers to build contextual representations (i.e., embeddings) and predict the next token. [2]

flowchart LR
    subgraph Input
        T[Token Sequence]
    end

    subgraph "Tokenizer"
        T --> ID[Integer IDs]
    end

    subgraph "Embeddings"
        ID --> E[Token Embeddings]
    end

    subgraph "Transformer"
        subgraph Encoder
            E --> A1[Attention]
            A1 --> FF1[Feed-Forward]
        end
        subgraph Decoder
            FF1 --> A2[Attention]
            A2 --> FF2[Feed-Forward]
        end
    end

    subgraph "Output"
        FF2 --> C[Contextual Representations]
        C --> P[Next Token Prediction]
    end

    subgraph "Context Window"
        CW["Max tokens (input + output + reasoning)<br />Exceeded → truncate/drop"]
    end

    E -.-> CW

  • A token is a discrete unit produced by breaking a sequence (e.g. into words, subwords, punctuation, patches, frames), mapped to a unique integer identifier so the model operates over a fixed vocabulary.

    Use the tokenizer tool, built with the tiktoken library, to see how many tokens are in a particular string of text. [4]

  • A context window is the maximum number of tokens (input, output, and reasoning tokens) that an LLM can process in a single request, beyond which any content is truncated or dropped. [4]

    When the prompt exceeds the available context, the application must manage the input length—for example by truncating older messages, summarizing prior turns, or using a sliding window of recent tokens so the most relevant content remains visible.

  • An embedding is a vector representation of a token that encodes linguistic and semantic information from context, so that tokens used in similar contexts have similar vectors (e.g. measurable by cosine similarity). [3]

    flowchart TB
    subgraph "Token → Embedding Lookup"
        T1["token: 'cat'"] --> E1["embedding: [0.2, 0.8, 0.1, …]"]
        T2["token: 'dog'"] --> E2["embedding: [0.3, 0.7, 0.2, …]"]
        T3["token: 'xylophone'"] --> E3["embedding: [-0.5, 0.1, -0.9, …]"]
    end

    subgraph "Similarity (e.g. cosine)"
        E1 <-.->|"high similarity"| E2
        E1 -.->|"low similarity"| E3
        E2 -.->|"low similarity"| E3
    end

    N["Similar context → similar vectors"]
    E1 --> N
    E2 --> N

1.2. BERT and GPT

  • BERT (Bidirectional Encoder Representations from Transformers) is an encoder-only model that uses bidirectional self-attention (each token attends to the full sequence) and is trained with masked language modeling for understanding tasks such as ranking and classification rather than generation. [5]

    Google Search uses BERT-style models to interpret search queries and rank results.

    • Because BERT sees the full sequence at once, it captures nuance that keyword matching misses—for example, the difference between "medicine to someone" and "medicine for someone," or the intent behind long, natural queries like "do you need a prescription to get medicine at a pharmacy."

    • In retrieval pipelines, a bi-encoder (encoding query and passages separately, then comparing embeddings) often does a fast initial retrieval, and a cross-encoder (encoding query and passage together) re-ranks the top candidates for better relevance.

  • GPT (Generative Pre-trained Transformer) is a decoder-only variant that uses causal (masked) self-attention (each token attends only to itself and previous tokens), trained for next-token prediction and suited for autoregressive text generation. [6]

    The term GPT is also used as a product name for OpenAI’s GPT series (e.g. GPT-4o, GPT-5) that power ChatGPT.

1.3. Prompts and Completions

LLMs are prompt–completion systems, with input as the prompt (instruction or conditioning) and output as a completion generated token-by-token. [2]

flowchart LR
    I["Input<br/>Prompt / Messages"] --> M["LLM Model"]
    M --> O["Output<br/>Completion / Response"]

  • A message is a single, discrete turn within a conversation, which is an object containing a role (who is speaking: system, user, tool or assistant) and content (what was said). [7] [8]

    • A system message, typically the first in a prompt, sets the AI’s overall behavior and persona by providing high-level instructions.

      { "role": "system", "content": "You are a helpful assistant that provides concise answers." }

    • A user message conveys the input provided by the end-user or agentic application to elicit a response to a specific question or instruction.

      { "role": "user", "content": "What is the capital of France?" }

    • An assistant message holds the model’s responses, which can be either a final answer or a request to use a tool.

      { "role": "assistant", "content": "The capital of France is Paris." }

    • A tool message provides the output of a function call back to the model, allowing it to process the result of an external action.

      { "role": "tool", "content": "{ \"temperature\": \"22\", \"unit\": \"celsius\" }", "tool_call_id": "call_abc123" }"

  • A prompt, representing the full message history processed by the model to generate a response, typically begins with an optional system message, followed by alternating user messages for user input and assistant messages for model responses, with tool messages providing function outputs after assistant tool calls.

    [
  {
    "role": "system",
    "content": "You are a helpful assistant."
  },
  {
    "role": "user",
    "content": "What's the weather in Boston?"
  },
  {
    "role": "assistant",
    "content": null,
    "tool_calls": [{
      "function": {
        "name": "get_current_weather",
        "arguments": "{ \"location\": \"Boston, MA\" }"
      }
    }]
  },
  {
    "role": "tool",
    "content": "{ \"temperature\": \"22\", \"unit\": \"celsius\" }",
    "tool_call_id": "call_abc123"
  }
]

1.4. RAG

Retrieval-Augmented Generation (RAG) is a powerful technique that addresses LLMs' frozen and limited knowledge by providing relevant, untrained context for each prompt.

flowchart LR
    U[User Question] --> QE[Query Embedding]
    QE --> VS[(Vector Store)]
    KB[Knowledge Base Documents] --> CH[Chunk + Embed]
    CH --> VS
    VS --> RC[Retrieve Top-K Chunks]
    RC --> AP[Augmented Prompt]
    U --> AP
    AP --> LLM[LLM]
    LLM --> A[Grounded Answer]

  • A knowledge base is broken into chunks, converted into numerical embeddings by a specialized model, and stored in a vector database.

  • A user’s question is converted into an embedding to retrieve the relevant document chunks from the vector database that are then placed into the prompt with the original question to augment the generation of the model.

1.5. Tool Calling

Tool calling is a powerful mechanism that allows developers to enable an LLM to interact with external systems and overcome its inherent limitations.

While the terms are often used interchangeably, it’s helpful to think of a tool as the general capability given to the model, and a function as the specific code implementation of that tool.

A tool calling is a process where the model, after receiving a user’s message and a list of available tools from the application, responds with a tool_calls object that instructs the application to execute a specific function, and gives the call result back to the model to generate the final response. [9]

sequenceDiagram
    actor User
    participant App as Application
    participant LLM as Model
    participant Tool as Weather Tool

    User->>App: Ask question
    App->>LLM: Messages + tool definitions
    LLM-->>App: tool_calls(get_current_weather)
    App->>Tool: Execute function call
    Tool-->>App: Return tool result
    App->>LLM: Append tool message
    LLM-->>App: Final answer
    App-->>User: Response

  1. The application sends the user’s message and a list of available tools to the model.

    {
  "model": "llama3.2:1b",
  "messages": [
    { "role": "user", "content": "What is the weather like in Boston?" }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_current_weather",
        "description": "Get the current weather in a given location",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "The city and state, e.g. San Francisco, CA"
            },
            "unit": {
              "type": "string",
              "enum": ["celsius", "fahrenheit"]
            }
          },
          "required": ["location"]
        }
      }
    }
  ],
  "stream": false
}

    • The model responds with a tool_calls object, instead of a text answer.

      {
  // ...
  "message": {
    "role": "assistant",
    "content": "",
    "tool_calls": [
      {
        "function": {
          "name": "get_current_weather",
          "arguments": { "location": "Boston, MA" }
        }
      }
    ]
  },
  // ...
}

    • The application executes the requested function (e.g., get_current_weather), obtains the result (e.g., {"temperature": "22", "unit": "celsius"}), and sends it back to the model in a tool message.

      {
  "role": "tool",
  "content": "{ \"temperature\": \"22\", \"unit\": \"celsius\" }",
  "tool_call_id": "call_abc123"
}

    • With the tool’s result in context, the model then generates the final, user-facing answer.

      {
  "role": "assistant",
  "content": "The current weather in Boston is 22 degrees Celsius."
}

1.6. Thinking and Reasoning

  • Chain of Thought (CoT) is a prompting and reasoning technique that asks a model to show its step-by-step reasoning before giving a final answer.

    • It can be triggered by explicit instructions (e.g., “Let’s think step by step,” “Solve step by step”) or by including worked examples in the prompt.

    • By making the reasoning visible, CoT improves performance on multi-step math, logic, and planning tasks, and is a widely used prompt-engineering method for boosting reasoning quality in standard LLMs.

  • Built-in reasoning is a native capability of advanced models (e.g., OpenAI o-series, Claude) trained with reinforcement learning to produce long internal chains of thought before responding, to autonomously plan multi-step strategies, evaluate task complexity, and determine optimal tool sequences for agentic workflows, moving beyond the mere syntactic pattern-matching typical of simple tool-use models. [10] [11]

    {
  "model": "qwen3.5:2b",
  "messages": [
    { "role": "user", "content": "What is the weather like in Boston?" }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_current_weather",
        "description": "Get the current weather in a given location",
        "parameters": {
          "type": "object",
          "properties": { "location": { "type": "string" } }
        }
      }
    }
  ],
  "stream": false
}
    {
  // ...
  "message": {
    "role": "assistant",
    "content": "",
    "reasoning": "The user is asking about the weather in Boston. I have access to a get_current_weather ...",
    "tool_calls": [
      {
        "function": {
          "name": "get_current_weather",
          "arguments": { "location": "Boston, MA" }
        }
      }
    ]
  },
  // ...
}

1.7. ReAct

ReAct (Reason and Act) is a technique that uses a system message to guide a model through an iterative Thought-Action-Observation loop to solve multi-step problems and derive a final answer.

flowchart LR
    U[User Goal] --> T[Thought<br/>Reason and plan]
    T --> A[Action<br/>Tool call]
    A --> O[Observation<br/>Tool result]
    O --> D{Solved?}
    D -- No --> T
    D -- Yes --> F[Final Answer]

  1. Thought: The model first thinks out loud by generating text that outlines its reasoning, analyzes the problem, and forms a plan.

  2. Action: Based on its thought process, the model outputs a structured request to use a specific tool (e.g., a tool_calls object).

  3. Observation: The application executes the requested tool, and the result of that tool (the observation) is fed back into the prompt for the next cycle.

    {
  "model": "phi4-mini:3.8b",
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant that can use tools. To solve problems, you must reason about a plan and then take an action.
When you need to use a tool, respond *only* with the following format:

Thought:
Your reasoning and plan for the next step.

Action:
A single tool call in a JSON object."
    },
    {
      "role": "user",
      "content": "What is the weather like in Boston?"
    }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_current_weather",
        "description": "Get the current weather in a given location",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "The city and state, e.g. San Francisco, CA"
            }
          }
        }
      }
    }
  ],
  "stream": false
}
    Thought:
To provide an accurate answer to this question, I need current weather information for a specific location—in this case, Boston.

Action:
```json
{
  "type": "function",
  "function": {
    "name": "get_current_weather",
    ...
  }
}
```

2. Agents

An agent is a composite of an LLM, tools, and an orchestration loop (e.g. ReAct), forming an autonomous system that perceives environments, makes decisions, plans and executes actions to achieve complex goals, and shifts from passive content generation to active problem-solving.

  • OpenCode is an open-source, provider-agnostic, terminal-first agent (TUI) that autonomously plans, implements, and refactors code across over 75 AI models.

  • Claude Code is Anthropic’s coding agent that assists with writing, editing, and debugging code, navigating codebases, and running commands in an integrated development workflow.

  • Cursor is an AI-native developer platform with an Agent Mode (GUI/CLI accessible) for planning multi-file refactors, running terminal tests, and handing off tasks to background cloud agents.

  • GitHub Copilot is an ecosystem-integrated agent platform to automate the entire issue-to-PR lifecycle using a specialized Squad of Agents (Plan, Code, Repair, Review) for development tasks within GitHub, VS Code, and Visual Studio.

  • Codex is OpenAI’s coding agent that reads, edits, and runs code to speed up development, fix bugs, and navigate codebases, with Codex Cloud running those tasks in the background in parallel in a dedicated cloud environment.

  • Gemini CLI is an open-source, terminal-native agent providing direct command-line access to Gemini AI for code generation, automation, grounding with Google Search, and MCP extensions.

  • OpenWork is an open-source, provider-agnostic agent for work and productivity that automates administrative tasks, manages workflows, and coordinates across tools and sub-agents.

  • Claude Desktop is an AI application featuring Cowork, an autonomous agentic mode for administrative productivity that manages local files, organizes directories, and coordinates sub-agents to process complex document workflows.

  • ChatGPT is an AI application featuring Operator, an autonomous agentic mode that performs web-based tasks such as booking travel and completing online forms.

  • Microsoft 365 Copilot is an enterprise productivity agent that orchestrates work across the Office suite, using agentic skills to manage inboxes, synthesize meeting data, and automate corporate workflows.

2.1. Memory

Memory is the mechanism an agent uses to store and retrieve information across turns and sessions, keeping state beyond what fits in a single prompt or context window, and its management—including truncation or summarization—is the application’s responsibility. [12]

flowchart LR
    U[User Message] --> ST[Short-term Memory<br/>Session History]
    ST --> P[Prompt Assembly]
    P --> LLM[LLM]
    LLM --> R[Response]
    R --> ST

    LT[(Long-term Memory<br/>Vector Store / DB)]
    ST -->|Summaries / facts| LT
    LT -->|Relevant retrieval| P

  • Short-term memory is the current conversation session’s message history, passed as the prompt to the model and dropped when the session ends unless the application persists it.

  • Long-term memory is persistent storage (e.g. vector store, database) that the agent reads from and writes to across sessions for facts, summaries of past conversations, or user preferences, often via RAG-style retrieval or explicit updates by the agent.

2.2. MCP (Model Context Protocol)

The Model Context Protocol (MCP) is an open-source standard, like a USB-C port for devices, for connecting AI applications to external systems, operating on a client-server architecture in which hosts coordinate clients that connect to servers to provide context. [13]

flowchart LR
    subgraph Host["MCP Host (IDE / CLI / App)"]
        User[User]
        Agent[LLM Agent]
        Client[MCP Client]
        User --> Agent
        Agent <--> Client
    end

    Client <--> Server[MCP Server]

    subgraph External["External Systems"]
        Tool["Tools (actions)"]
        Resource["Resources (data)"]
        Prompt["Prompts (templates)"]
    end

    Server --> Tool
    Server --> Resource
    Server --> Prompt

  • MCP servers are programs that expose specific capabilities to AI applications through standardized protocol interfaces, through three building blocks tools, resources, and prompts.

    An MCP Server is the program that serves context data, which can execute either locally (e.g., Claude Desktop’s filesystem server using STDIO for a single client) or remotely (e.g., Sentry’s server using Streamable HTTP for many clients).

    A JSON-RPC 2.0 protocol is used for the data layer to define the actual communication and its core primitives, including tools (executable actions), resources (data sources), prompts (reusable prompt templates), and notifications (for real-time updates).

    • Tools are functions that the model actively decides to call to perform actions like searching for flights or sending messages, giving it direct control over when and how it interacts with the outside world.

    • Resources are passive, read-only data sources, such as files or knowledge bases, that the application makes available to provide the model with contextual understanding, like retrieving a document.

    • Prompts are pre-built, reusable instruction templates defined by the application to guide the model on how to use specific tools and resources to accomplish a complex task, such as planning a vacation.

  • MCP clients are components instantiated by host applications to communicate with a dedicated MCP server (one client per server), using context provided by that server and exposing capabilities to the host to enable richer interactions.

    • Elicitation provides a structured way for a server to request specific user information on demand like asking for travel preferences to finalize a booking.

    • Roots securely communicate the client’s intended scope by defining which directories a server can access like a travel server reading a user’s calendar.

    • Sampling keeps the client in complete control of permissions by allowing a server to request an LLM completion for agentic workflows like picking the best flight from a list.

  • MCP hosts (e.g. an IDE, a CLI, or a desktop app) are applications that instantiate and coordinate MCP clients with server connections defined in config files (global or project-local) in host-specific formats (e.g. JSON for Gemini and Cursor, TOML for Codex).

    When searching for MCP servers, consider the following:

    • Gemini CLI configures MCP servers under mcpServers in ~/.gemini/settings.json (global) or .gemini/settings.json (per-project).

      {
  "mcpServers": { (1)
    "serverName": { (2)
      "command": "path/to/server", (3)
      "args": ["--arg1", "value1"], (4)
      "env": { (5)
        "API_KEY": "$MY_API_TOKEN"
      },
      "cwd": "./server-directory", (6)
      "timeout": 30000, (7)
      "trust": false (8)
    }
  }
}
      1 The mcpServers object defines the set of MCP servers to discover and connect to, keyed by server name.
      2 The serverName object provides one server’s configuration and its key is used for status display and tool-name prefixing on conflicts.
      3 One transport is selected by providing command (local stdio), url (SSE), or httpUrl (streamable HTTP).
      4 The args array is used with command and provides argv parameters for the local stdio process.
      5 The env object is used with command and provides environment variables for the local stdio process, supporting $VAR and ${VAR} expansion.
      6 The cwd value is used with command and sets the working directory for starting the local stdio process.
      7 The timeout value sets the request timeout in milliseconds with a documented default of 600000ms when omitted.
      8 The trust flag controls confirmation behavior, where true bypasses tool-call confirmations and false preserves them. 
      {
  "mcpServers": {
    "sqlite": {
        "command": "uvx",
        "args": ["mcp-server-sqlite", "--db-path", "/tmp/test.db"]
    },
    "mssql": {
      "command": "dotnet"
      "args": ["dnx", "Alyio.McpMssql", "--prerelease", "--yes"],
      "env": {
        "MCP_MSSQL_CONNECTION_STRING": "Server=127.0.0.1;User ID=sa;Password=<YourStrong@Passw0rd>;Encrypt=True;TrustServerCertificate=True;"
      }
    }
  }
}

    • Cursor Agent configures MCP servers in ~/.cursor/mcp.json (global) or .cursor/mcp.json (per-project).

      {
  "sqlite": {
    "command": "uvx",
    "args": ["mcp-server-sqlite", "--db-path", "/tmp/test.db"]
  },
  "mssql": {
    "command": "dotnet"
    "args": ["dnx", "Alyio.McpMssql", "--prerelease", "--yes"],
    "env": {
      "MCP_MSSQL_CONNECTION_STRING": "Server=127.0.0.1;User ID=sa;Password=<YourStrong@Passw0rd>;Encrypt=True;TrustServerCertificate=True;"
    }
  }
}

    • OpenCode AI configures MCP servers in ~/.config/opencode/opencode.json (global) or opencode.json (per-project).

      {
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "sqlite": {
      "type": "local",
      "command": ["uvx", "mcp-server-sqlite", "--db-path", "/tmp/test.db"],
      "enabled": true
    },
    "mssql": {
      "type": "local",
      "enabled": true,
      "command": ["dotnet", "dnx", "Alyio.McpMssql", "--prerelease", "--yes"],
      "environment": {
        "MCP_MSSQL_CONNECTION_STRING": "Server=127.0.0.1;User ID=sa;Password=<YourStrong@Passw0rd>;Encrypt=True;TrustServerCertificate=True;"
      }
    }
  }
}

    • Codex configures MCP servers in ~/.codex/config.toml (global) or .codex/config.toml (per-project).

      [mcp_servers.sqlite]
command = "uvx"
args = ["mcp-server-sqlite", "--db-path", "/tmp/test.db"]

[mcp_servers.mssql]
command = "dotnet"
args = ["dnx", "Alyio.McpMssql", "--prerelease", "--yes"]

[mcp_servers.mssql.env]
MCP_MSSQL_CONNECTION_STRING = "Server=127.0.0.1;User ID=sa;Password=<YourStrong@Passw0rd>;Encrypt=True;TrustServerCertificate=True;"

2.3. Skills

An agent skill is a lightweight, open-format folder of instructions, scripts, and resources for extending AI agent capabilities with specialized knowledge and workflows. [14]

.agents/
└── skills/
    └── my-skill/
        ├── SKILL.md        # Required: instructions + metadata
        ├── scripts/        # Optional: executable code
        ├── references/     # Optional: documentation
        └── assets/         # Optional: templates, resources

A skills-compatible agent manages context through progressive disclosure by discovering skills in configured directories to load only metadata (name, description) at startup, then matching user tasks to activate full SKILL.md instructions and execute scripts or resources only as needed.

The SKILL.md file consists of a YAML metadata header for discovery followed by an unrestricted Markdown body containing the specific instructions and logic required for the agent to execute the task effectively.

---
name: [skill-id]
description: [Short summary for discovery]
---

# [Skill Name]

## When to use
- Use when [Trigger Scenario A] or [Trigger Scenario B] occurs.

## Instructions
1. **Analyze:** Identify [Key Input].
2. **Execute:** Perform [Action] using bundled resources.
3. **Output:** Return [Result Format].

2.4. AGENTS.md

AGENTS.md is a simple, open-format markdown file that serves as a README for coding agents, complementing README.md (for humans) with a dedicated place for context and instructions (e.g. setup, build, test, conventions), with no required structure and support across Codex, Cursor, and others. [15]

To verify that an agent is reading AGENTS.md, a test rule can be added whose behavior is easy to observe and unlikely to occur by chance. The following snippet can be placed in AGENTS.md for that purpose:

### TEST RULE
- Whenever the user asks for a 'system check', the agent must respond with the word: "BANANAPANTS".
- All code comments must start with a 🍎 emoji.

After the file is saved, a "system check" request can be sent in chat; a response of "BANANAPANTS" indicates that the corresponding AGENTS.md is in effect.

A small code change can then be requested (e.g. "add a one-line comment to this function"); if the resulting comment starts with the 🍎 emoji, the test rule is being applied.

It confirms both that AGENTS.md is loaded and which file takes precedence when project-level and user-level (or nested) files exist.

Configure Gemini CLI to use AGENTS.md in .gemini/settings.json:

{
  "context": {
    "fileName": ["GEMINI.md", "AGENTS.md"]
  }
}

2.5. MAS (Multi-Agent Systems)

A multi-agent system (MAS) is a distributed network of autonomous agents that collaborate or compete within a shared environment to solve complex, large-scale tasks through collective decision-making, whereas a single-agent system relies on one entity working in isolation with centralized control, making it better suited for simpler, well-defined tasks.

A multi-agent system operates through a continuous cycle—structured as a recursive, stateful graph—where individual agents perceive the environment and reason via an LLM brain to decompose intricate processes into specialized tasks, executing actions coordinated by orchestration frameworks like CrewAI or LangGraph to transform high-level goals into structured, autonomous workflows.

graph TD
    User([User Intent]) --> LeadAgent[Lead Agent]

    subgraph "Recursive Stateful Graph"
        LeadAgent -->|Perceive| Env[Environment]
        Env -->|Data| Brain{LLM Brain}
        Brain -->|Decompose| Tasks[Specialized Tasks]

        subgraph "Agent Swarm"
            Tasks --> AgentA[Agent A: Specialist]
            Tasks --> AgentB[Agent B: Specialist]
            Tasks --> AgentC[Recursive Lead]
            AgentC -->|Sub-Tasks| SubAgent1[Sub-Agent 1]
        end

        AgentA & AgentB & SubAgent1 -->|Actions| Orchestrator[Orchestration Framework]
        Orchestrator -->|State Update| Env
        Orchestrator -.->|Loop/Self-Correct| Brain
    end

    Orchestrator --> Result([Structured Workflow Output])

    classDef lead fill:#f96,stroke:#333,stroke-width:2px;
    classDef swarm fill:#dcf,stroke:#333;
    class LeadAgent,AgentC lead;
    class AgentA,AgentB,SubAgent1 swarm;

A2A (Agent-to-Agent) is an open interoperability protocol that functions as a universal language, allowing autonomous agents to discover each other, communicate intent, and collaborate across different frameworks and platforms without custom integrations. [17]

2.6. ACP (Agent Client Protocol)

Agent Client Protocol (ACP) is an LSP‑like open standard for AI coding agents, giving code editors/IDEs a common framework to read project files, apply changes, and stream results across environments to reduce vendor lock‑in.

2.7. LangChain and LangGraph

LangChain and LangGraph are the de facto standards for orchestrating complex agentic workflows, providing the nervous system required to manage state, memory, and iterative logic. While alternatives like Microsoft Semantic Kernel or Spring AI offer specialized abstractions for specific enterprise ecosystems, the LangChain suite remains the most comprehensive framework for building and scaling sophisticated, autonomous multi-agent swarms. [18]

  • LangChain is an open-source framework that provides the foundational building blocks for LLM application development, offering a standardized model interface to prevent vendor lock-in and a vast library of integrations for diverse tools and data sources.

    LangChain is best for linear sequences (DAGs) where data flows from one point to another. 
    model = ChatOllama(model="llama3.2:1b")
prompt = ChatPromptTemplate.from_template("Tell me a fun fact about {city}")

# A simple linear DAG: Prompt -> LLM -> String
chain = prompt | model | StrOutputParser()

print(chain.invoke({"city": "San Francisco"}))
    @tool
def get_weather(city: str) -> str:
    """Get the current weather for a specific city."""
    return f"It's 25°C and sunny in {city}!"

# Bind the tool to the LLM to enable reasoning over actions
model_with_tools = ChatOllama(model="llama3.2:1b").bind_tools([get_weather])

response = model_with_tools.invoke("What is the weather in Paris?")
# Returns structured 'tool_calls' rather than just plain text
print(response.tool_calls)
    model = ChatOllama(model="llama3.2:1b")
prompt = ChatPromptTemplate.from_template("Answer based on: {context}. Question: {question}")
# Simple lambda acting as a mock retriever
retriever = lambda x: "The weather protocol requires checking the local sensor."

rag_chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | model
    | StrOutputParser()
)

print(rag_chain.invoke("What is the weather protocol?"))

  • LangGraph is an extension of the LangChain ecosystem designed for building durable, stateful multi-agent systems by representing workflows as cyclic graphs, enabling agents to self-correct through iterative loops and pause for human-in-the-loop interactions.

    # LangGraph is the killer for complex agents because it supports cycles.

# Defining a stateful, cyclic graph
workflow = StateGraph(AgentState)

# Define nodes (the "Brains") and edges (the "Paths")
workflow.add_node("researcher", research_node)
workflow.add_node("reviewer", review_node)

# Create a cycle: The Reviewer can send the Researcher back to work
workflow.add_conditional_edges(
    "reviewer",
    should_continue,
    {
        "retry": "researcher",  # The Cycle!
        "complete": END
    }
)

app = workflow.compile()

  • LangSmith is a unified DevOps platform for the agentic lifecycle that provides full visibility into an LLM’s reasoning process, allowing developers to debug, test, evaluate, and monitor complex chains and graphs from prototype to enterprise-scale production.

3. Non-Determinism and Hallucinations

Non-determinism and hallucinations are core LLM limitations that influence how AI systems are designed and operated.

  • LLMs are indeed trained as probabilistic models to predict the probability distribution of the next token based on a given context, using temperature to scale logits and top-k/p (nucleus) parameters to filter the sampling pool, resulting in non-deterministic completions. [19]

  • Hallucinations occur because LLMs prioritize linguistic plausibility over factual accuracy, generating fluent-but-false assertions when the training data is sparse, contradictory, or when the model over-extrapolates patterns from its internal weights.

3.1. Hyperparameters

Temperature, top‑k, and top‑p (nucleus sampling) are three key hyperparameters that determine how the model selects tokens at each step, balancing consistency, creativity, and variability.

  • Temperature (typically 0 - 2) rescales the model’s logits (pre‑softmax scores), adjusting the probability distribution before sampling.

    • A temperature setting of 1 uses the standard probability distribution.

    • A higher temperature flattens the distribution, making lower-probability tokens more likely, so outputs are more varied.

    • A lower temperature sharpens the distribution toward higher-probability tokens, producing more consistent outputs.

    • A zero temperature triggers greedy decoding, always selecting the highest‑scoring token for deterministic generation.

    • Use low temperature for precise, deterministic tasks (summaries, factual QA) and higher temperature for creative tasks (story generation, brainstorming).

  • Top‑k sampling limits the candidate pool to the k most probable tokens set before sampling.

    • Tokens outside that set are excluded (probability = 0), and the remaining probabilities are renormalized.

    • Smaller k reduces diversity and excludes long‑tail, very-low-probability tokens, while larger k increases diversity within the top candidates.

  • Top-p sampling selects the smallest set of tokens whose cumulative probability reaches p (e.g., 0.9).

    • Tokens are sorted by probability and included until the cumulative sum reaches p, then the rest are discarded and the remaining probabilities are renormalized.

    • Top‑k uses a fixed number of tokens, while top‑p uses a variable set based on cumulative probability at each generation step.

    • Top‑p is often preferred for creative or open-ended generation because it adapts to probability distributions dynamically, preventing overly unlikely tokens while still allowing variety.

    • A combined strategy—moderate temperature with top‑p or top‑k—can give balanced outputs that are both coherent and varied.

3.2. HITL (Human-in-the-Loop)

Human-in-the-Loop (HITL) is a design paradigm where humans actively participate in supervision or decision-making at critical points in an AI workflow, creating an iterative cycle of the system proposing, the human reviewing or correcting, and the system proceeding with validated output. [iibm-topics-hitl]

flowchart LR
    A[Agent proposes plan or action] --> G{High risk or ambiguity?}
    G -- No --> E[Execute automatically]
    G -- Yes --> H[Human review]
    H -->|Approve| E
    H -->|Reject / Edit| C[Provide correction or context]
    C --> A
    E --> O[Outcome]
    O --> L[Log feedback for future runs]

HITL provides a vital safeguard against LLM non-determinism and hallucinations by enabling domain experts to verify stochastic outputs and intercept factual errors before they impact downstream operations.

  • In machine learning, HITL contributes to model training through data labeling in supervised learning, preference feedback in reinforcement learning from human feedback (RLHF), and targeted annotation in active learning where the model selects its most uncertain predictions for human review.

  • In agentic AI systems, HITL interventions are typically reactive and triggered only when the system detects ambiguity, missing information, or high-risk actions to keep human involvement meaningful without interrupting every step.

    • The agent proposes actions and the human validates, approves, or rejects them, for example a coding assistant may request confirmation before running a shell command.

    • The agent interrupts reactively, pausing only when it detects ambiguity, missing information, or high-risk actions rather than at every step.

    • The agent requests input from the human when it lacks domain-specific context and then continues with the enriched context.

    • The human reviews a draft and requests refinements iteratively while the agent regenerates output in a feedback loop until the result is satisfactory.

3.3. AI-Assisted Coding

Modern AI-assisted development leans on spec-driven and test-driven practices to mitigate non-determinism and hallucinations.

  • Spec-driven development (SDD) is a paradigm where specifications—not code—serve as the primary source of truth. [21] [22] [23]

    • SDD represents the next logical abstraction in programming—advancing from machine code and high-level languages to natural language and declarative intent, where implementation is treated as a mere derived artifact.

    • SDD is not yet a canonical or universally standardized methodology; rather, it remains an emerging set of agentic workflows and best practices that vary across AI-integrated environments.

  • Test-Driven Development (TDD) is a practice of writing failing tests first (red), adding minimal code to pass them (green), then refactoring—using tests as executable specifications that drive design and support safe refactoring through rapid feedback and regression protection.

    • TDD provides a deterministic safety net for non-deterministic AI outputs, transforming ambiguous natural language requests into verifiable objective truths.

    • TDD establishes an automated run-and-fix loop, enabling agents to iterate independently by leveraging compiler errors and test failures to self-correct without constant human intervention.

    • TDD optimizes agent reliability by ensuring the AI first confirms its understanding of the requirements through test criteria before committing to a specific implementation.

Bibliography