Unit 5: LLM-Driven Agents and Generative Workflows

I. Orientation — From Language Models to Goal-Directed Agents

An LLM-driven agent is a software system in which a large language model interprets goals, selects actions, uses external resources, observes results, and adapts its behavior. Unlike a basic chatbot that produces one response per prompt, an agent operates through a repeated perception–reasoning–action loop.

A. Defining Characteristics

The governing principle is that an LLM supplies flexible language-based reasoning while deterministic software controls execution, permissions, state, and validation.

• Goal-directed operation: The agent receives an objective such as “compare quarterly sales and draft a report,” rather than only a single completion request.
• Iterative control loop: A typical cycle is:

Goal → Observe state → Plan → Act → Inspect result → Update state → Repeat

• Core components:
  • Model: Interprets instructions and proposes decisions.
  • Tools: Search engines, databases, calculators, code runners, or APIs.
  • Memory: Stores conversation state, retrieved knowledge, and task history.
  • Controller: Enforces stopping rules, permissions, budgets, and error handling.
• Generative workflow: Outputs may include text, code, images, structured records, or sequences of API operations.
• Probabilistic behavior: LLM outputs are not guaranteed to be correct or identical across runs; schemas, validators, and human approval reduce this uncertainty.
• Agent-environment boundary: The model suggests an action, but trusted application code should authenticate, authorize, execute, and log it.

II. Agent Architecture — Connecting Models to Action Loops

A. Integration of LLMs into agentic frameworks

Integration places an LLM inside an orchestration layer that converts model outputs into controlled actions and feeds observations back into the model.

• Input construction: The framework combines the user goal, system rules, available-tool descriptions, relevant memory, and current state into the model context.
• Structured decisions: Instead of accepting free-form commands, the framework may require a typed response:

{
  "action": "get_weather",
  "arguments": {"city": "Delhi"},
  "reason": "Weather data is required for the itinerary."
}

• Execution boundary: The orchestrator maps get_weather to approved application code; the model does not directly execute arbitrary functions.
• Observation feedback: A result such as {"temperature_c": 31} becomes a new observation, allowing the agent to revise its plan.
• Control policies:
  • Limit the number of iterations, tokens, execution time, and monetary cost.
  • Require human approval before payments, deletions, messages, or production changes.
  • Reject malformed arguments through JSON Schema or equivalent validation.
• Reliability principle: Use the LLM for ambiguous interpretation and planning, but use ordinary code for arithmetic, access control, and invariant checks.

III. Planning and Reasoning — Decomposing Goals into Steps

A. Chain-of-thought reasoning for planning

Chain-of-thought reasoning uses intermediate reasoning steps to transform a complex goal into an ordered and revisable plan.

• Task decomposition: “Organize a conference” can become venue selection, speaker scheduling, budgeting, registration, and notification tasks.
• Dependency ordering: If task (T_2) requires the output of (T_1), the plan must satisfy:

T₁ → T₂

Here, (T_1) is the prerequisite task, (T_2) is the dependent task, and the arrow denotes execution order.

• Planning patterns:
  • Plan-then-execute: Produce a complete plan first, then perform its steps.
  • Interleaved planning: Choose one action, inspect the result, and plan again.
  • Reflection: Evaluate whether an attempted result satisfies explicit criteria before continuing.
• Production practice: Systems should request concise plans, tool calls, or verifiable intermediate artifacts rather than depend on unrestricted internal reasoning traces.
• Limitations: A coherent plan may still rely on false assumptions; grounding, tool results, validators, and replanning are therefore necessary.
• Concrete control: A planner might represent progress as pending → running → completed/failed, making task state observable rather than merely conversational.

IV. Persistent Context — Extending the Agent Beyond Its Prompt

A. Memory augmentation

Memory augmentation gives an agent access to information that is absent from the model’s current input or fixed training data.

• Short-term memory: A message buffer or running summary preserves recent goals, decisions, and tool observations within one session.
• Long-term memory: Databases store durable facts such as user preferences, completed tasks, or prior outcomes across sessions.
• Semantic memory: Documents are converted into embedding vectors and retrieved by similarity. A common measure is cosine similarity:

similarity(q, d) = (q · d) / (||q|| ||d||)

Here, (q) is the query vector, (d) is a document vector, (q \cdot d) is their dot product, and (||\cdot||) denotes vector magnitude.

• Episodic memory: Records specific experiences—action, context, result, and timestamp—so the agent can reuse successful procedures.
• Retrieval-augmented generation: Retrieved passages are inserted into the prompt, allowing responses to cite current organizational knowledge rather than relying solely on model parameters.
• Memory risks: Outdated facts, malicious stored instructions, irrelevant retrieval, and privacy leakage require provenance, expiration rules, access controls, and deletion mechanisms.

V. External Capabilities — Safe Interaction with Software Systems

A. Tool-use and API orchestration by agents

Tool use enables an agent to obtain authoritative data or perform operations that language generation alone cannot accomplish.

• Tool specification: Each tool needs a name, purpose, argument schema, return schema, and documented failure conditions.
• Selection process: The LLM identifies a needed capability, chooses a permitted tool, supplies arguments, and interprets the returned observation.
• API orchestration: A multi-step travel workflow may call a location API, flight-search API, calendar API, and email service, passing validated outputs between them.
• Error handling:
  • Retry transient failures such as HTTP 503.
  • Correct invalid arguments after a schema error.
  • Stop or escalate when authentication fails or repeated calls exceed a limit.
• Security controls: Apply least-privilege credentials, domain allowlists, input sanitization, rate limits, audit logs, and confirmation for high-impact actions.
• Idempotency: Repeated requests should not duplicate side effects; an idempotency key can ensure that retrying a payment or booking request creates only one transaction.
• Prompt-injection defense: Content returned by websites or documents must be treated as untrusted data, not as authority to override system policies.

VI. Interleaved Reasoning and Acting — The ReAct Pattern

A. ReAct framework

The ReAct framework combines reasoning and action so that an agent can alternate between deciding what it needs and gathering evidence from its environment.

• Interaction sequence:

Question → Thought → Action → Observation → Thought → … → Final answer

• Thought: Identifies the next information need or subgoal.
• Action: Invokes a named tool with specific arguments.
• Observation: Captures the tool’s result, which grounds the next decision.
• Example pattern: For “What is the population density of a city?”, the agent retrieves population and area, then uses a calculator:

density = population / area

Here, density is measured in people per square kilometre when population is in people and area is in square kilometres.

• Advantage: Interleaving reduces reliance on unsupported recall because each decision can be revised using fresh observations.
• Limitation: Poor stopping criteria can cause repetitive tool calls or loops; maximum-step limits, duplicate-call detection, and explicit completion tests are essential.
• Trace handling: Applications may log actions and observations for auditing while exposing concise rationales rather than private model reasoning.

VII. Agent Development Platforms — Frameworks and Autonomous Loops

A. Introduction to LangChain Agents and AutoGPT

LangChain Agents and AutoGPT illustrate two approaches to assembling LLMs, tools, memory, and iterative task execution.

1. LangChain Agents:

   • Purpose: LangChain provides components for prompts, models, retrieval, tools, agent loops, and application state.
   • Agent behavior: A model selects among registered tools; an executor or graph-based workflow invokes them and returns observations.
   • Structured workflows: Developers can define explicit nodes, transitions, checkpoints, and human-approval stages, improving control over long-running processes.
   • Use case: A support agent may retrieve policy documents, query an order database, and draft a response without being permitted to issue refunds directly.

2. AutoGPT:

   • Purpose: AutoGPT popularized experimental autonomous agents that repeatedly generate subtasks, use tools, maintain memory, and pursue a broad objective.
   • Operating loop: The system evaluates its current goal, selects an action, records the result, and continues until completion or a stopping condition.
   • Contrast: LangChain is primarily a developer framework for constructing controlled applications; AutoGPT represents a more autonomy-oriented agent application pattern.
   • Limitations: Long loops may accumulate errors, consume excessive tokens, repeat actions, or drift from the original objective, making supervision and budgets necessary.

VIII. Multi-Agent Coordination — Dividing Complex Work

A. Autonomous task delegation

Autonomous task delegation allows a coordinator agent to assign specialized subtasks to other agents or services and combine their outputs.

• Role specialization: A research agent gathers evidence, an analysis agent processes data, and a writing agent creates the final document.
• Delegation record: Each assignment should specify the task, inputs, constraints, expected output schema, deadline, and acceptance criteria.
• Coordination structures:
  • Hierarchical: A manager creates tasks and reviews worker outputs.
  • Peer-based: Agents exchange results directly under a shared protocol.
• Result aggregation: The coordinator checks completeness, resolves contradictions, and synthesizes outputs rather than concatenating them blindly.
• Failure management: Timeouts, retries, alternative workers, and escalation rules prevent one failed subtask from blocking the whole workflow.
• Risks: Delegation can amplify hallucinations and obscure responsibility; provenance logs should identify which agent, model, tool, and data source produced each artifact.

IX. Practical Deployment — Organizational Value and Oversight

A. Applications in automation and decision support

LLM-driven agents are most valuable when they combine language understanding with bounded actions, reliable data, and explicit human accountability.

• Business automation: Agents can classify emails, extract invoice fields, update customer records, schedule meetings, and draft routine correspondence.
• Software operations: They can summarize incidents, inspect logs, propose patches, run approved tests, and prepare pull-request descriptions.
• Decision support: An agent may retrieve policies, compare alternatives, calculate indicators, and present evidence, but the accountable human retains the final decision.
• Domain applications:
  • Healthcare administration: Summarizing records or routing forms without independently diagnosing patients.
  • Finance: Explaining reports and detecting anomalies without autonomously approving high-risk transactions.
  • Education: Generating adaptive explanations while instructors verify correctness and appropriateness.
• Evaluation criteria: Measure task-success rate, factual accuracy, tool-call validity, latency, cost, safety violations, and human override frequency.
• Operational safeguards: Use sandboxing, permission tiers, monitoring, versioned prompts, rollback procedures, and approval gates.
• Central distinction: Automation executes predefined or bounded processes, whereas decision support supplies evidence and options; neither removes the need for governance when consequences are significant.