Unit 2: Prompt Engineering, Reasoning and Agent Architectures

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

A large language model (LLM) generates text by predicting tokens from a context, while an agent places the model inside a control loop that can observe state, plan actions, invoke tools, store information, and evaluate progress toward a goal.

• Governing principle: Model behavior is conditioned by instructions, examples, context, tool definitions, and prior messages rather than changed model weights.
• Prompt: The complete input context may include system instructions, user requests, demonstrations, retrieved documents, tool schemas, and previous outputs.
• Agent: An agent repeatedly maps its current state and goal to an action:
  
  TEXT

    a_t = π(g, s_t)
    s_(t+1) = T(s_t, a_t, o_(t+1))

  
  Here, t is the step number, g is the goal, s_t is the current state, a_t is the selected action, π is the decision policy, o_(t+1) is the resulting observation, and T is the state-update process.
• Core loop: A typical cycle is observe → reason/plan → act → inspect result → update state.
• Probabilistic character: Outputs can vary with model, context, sampling temperature, and decoding settings; prompting guides behavior but does not guarantee correctness.
• Evaluation standard: A good design is judged by task accuracy, reliability, cost, latency, safety, and compliance with output constraints.

II. Prompting Paradigms — Instructions, Demonstrations, and Intermediate Reasoning

A. Zero-shot prompting

Zero-shot prompting asks a model to perform a task using instructions but no task-specific input-output demonstrations.

• Structure: A strong zero-shot prompt specifies the role, task, relevant context, constraints, and required output format.
• Direct instruction: “Classify the review as positive, negative, or neutral. Return one label only” defines both the operation and response space.
• Instruction hierarchy: Higher-priority system or developer constraints govern lower-priority user content; quoted documents should be treated as data, not automatically as instructions.
• Best use: Zero-shot prompting suits familiar tasks such as summarization, extraction, rewriting, classification, and straightforward question answering.
• Advantages: It requires few tokens, is easy to maintain, and avoids demonstration examples that might accidentally bias outputs.
• Limitations: Ambiguous labels or unstated criteria can produce inconsistent interpretations; “brief,” for example, is less testable than “use at most 60 words.”
• Worked example:
  
  TEXT

    Extract the invoice number and total amount from the text.
    Return JSON with keys "invoice_number" and "total".
    Use null when a value is absent.

  
  This prompt converts an open-ended extraction task into a constrained data-mapping task.

B. Few-shot prompting

Few-shot prompting provides several demonstrations so that the model can infer the intended task pattern, labels, style, or transformation.

• Demonstration form: Each example normally contains an input and its desired output, followed by the new input to process.
• In-context learning: The model adapts from examples within the current context; its stored parameters are not updated.
• Example quality: Demonstrations should be correct, representative, consistently formatted, and relevant to likely inputs.
• Coverage: Examples should include meaningful boundary cases, such as neutral sentiment alongside positive and negative sentiment.
• Ordering effects: Recent examples and recurring labels may disproportionately influence generation, so balanced ordering reduces accidental bias.
• Contrast with zero-shot:
  1. Zero-shot: Defines behavior through explicit verbal instructions and consumes less context.
  2. Few-shot: Shows behavior through examples and is preferable when categories or formatting conventions are difficult to describe precisely.
• Worked example:
  
  TEXT

    Text: "Excellent battery life." Label: positive
    Text: "It works, but nothing stands out." Label: neutral
    Text: "The screen failed in two days." Label: negative
    Text: "Setup was simple and fast." Label:

  
  The demonstrations establish the three-label decision pattern before the final classification.

C. Chain-of-thought prompting

Chain-of-thought prompting encourages intermediate reasoning steps before a final answer, especially for multi-step problems.

• Purpose: Decomposition can improve performance when success requires arithmetic, symbolic transformation, constraint tracking, or several dependent inferences.
• Elicitation: A prompt may request a concise derivation, numbered justification, or intermediate calculation rather than an unsupported answer.
• Worked example: For “A ₹1,000 item receives a 20% discount and then 18% tax,” the grounded calculation is:
  
  TEXT

    Discounted price = 1000 × (1 − 0.20) = 800
    Final price = 800 × (1 + 0.18) = 944

  
  The intermediate value prevents the common error of combining percentages against the same base.
• Verification: Reasoning text is not proof of correctness; calculations and factual premises should still be checked with tools, tests, or independent criteria.
• Operational caution: Production systems often request concise justifications or structured evidence rather than unrestricted internal deliberation, reducing cost and irrelevant text.
• Alternative strategies: Self-consistency compares multiple candidate solutions, while decomposition solves explicit subproblems and combines their verified results.

III. Structured Interaction — Machine-Readable Outputs and Tools

A. Structured prompting including function calling

Structured prompting constrains model output to a schema, while function calling lets the model propose a named operation and validated arguments for external execution.

• Schema control: JSON schemas can define required fields, types, enumerations, and nested objects, making outputs easier for software to validate.
• Function definition: A tool specification typically contains a function name, description, parameter schema, and required arguments.
  
  JSON

    {
      "name": "get_weather",
      "parameters": {
        "type": "object",
        "properties": {
          "city": {"type": "string"},
          "unit": {"enum": ["C", "F"]}
        },
        "required": ["city", "unit"]
      }
    }

• Execution boundary: The model proposes get_weather({"city":"Delhi","unit":"C"}); application code validates and executes it, then returns the observation to the model.
• Reliability controls: Validate types, reject unknown fields, constrain enumerations, set timeouts, and handle missing or malformed arguments.
• Security boundary: Tool outputs and retrieved text are untrusted data; authorization must be enforced by application code rather than delegated to the model.
• Limitations: Valid syntax does not guarantee true values or an appropriate tool choice, so semantic checks and confirmation are necessary for consequential actions.

IV. Planning Architectures — Turning Objectives into Executable Actions

A. Prompt strategies for task planning

Task-planning prompts direct the model to decompose a complex request into ordered, testable units before execution.

• Plan specification: State the objective, available resources, constraints, deadline, and expected plan format.
• Decomposition: Convert a broad task into steps with identifiers, dependencies, required inputs, actions, and completion criteria.
• Dependency awareness: A step should run only after its prerequisites; data collection, for example, precedes analysis that depends on that data.
• Useful template:
  
  TEXT

    Goal: <desired outcome>
    Constraints: <limits>
    Resources: <tools and information>
    Produce steps with: ID, action, dependency, expected result, check.

• Plan-first versus interleaved planning:
  1. Plan-first: Produces a complete plan before acting; it offers coherence but can become stale after unexpected observations.
  2. Interleaved: Plans the next few steps, acts, and replans; it handles uncertainty but may lose global direction.
• Quality checks: Plans should be complete, non-duplicative, feasible with available tools, and measurable through explicit success conditions.
• Failure prevention: Prompts should require assumptions to be identified and irreversible actions to await authorization.

B. Goal-oriented action planning

Goal-oriented action planning selects actions by considering how each one changes the current state and moves the agent toward a target state.

• State-space model: A planning problem contains an initial state s₀, goal condition G, available actions A, action preconditions, and action effects.
• Action validity: An action is eligible only when its preconditions hold; “send report” requires a completed report and a verified recipient.
• Goal test: Execution can stop when G(s_t) = true, meaning the state at step t satisfies the goal condition.
• Action selection: A planner may minimize an estimated total cost:
  
  TEXT

    a* = argmin_a [c(a) + h(T(s_t, a), G)]

  
  Here, a* is the preferred action, c(a) is immediate action cost, T predicts the next state, and h estimates remaining cost to goal G.
• ReAct-style loop: The agent reasons about the next step, performs an action, observes the result, and revises its state before continuing.
• Recovery: If an API fails or information contradicts an assumption, the planner should retry safely, choose an alternative, revise the plan, or escalate.
• Control safeguards: Spending limits, tool permissions, maximum step counts, idempotency keys, and human approval prevent uncontrolled action sequences.

V. Persistent Context — Remembering Without Losing Control

A. Agent memory and state management

Agent memory preserves useful information across steps, while state management maintains the authoritative representation of the current task.

• Working memory: The active context holds the immediate goal, recent observations, pending actions, and relevant tool results.
• Episodic memory: Records past interactions or completed tasks, such as a previous troubleshooting sequence and its outcome.
• Semantic memory: Stores durable facts or preferences, often retrieved through keyword search or vector similarity.
• Procedural memory: Encodes reusable workflows, policies, or tool-use instructions, such as an approval process.
• State representation: Structured state can include goal, plan, completed_steps, artifacts, errors, and next_action.
• Update discipline: Every tool result should produce an explicit transition; append-only event logs aid auditing, while checkpoints support recovery.
• Context control: Summarization and retrieval reduce token use, but critical facts should remain structured because lossy summaries can omit constraints.
• Safety and privacy: Memory requires access control, retention limits, deletion mechanisms, provenance, and protection against storing unnecessary sensitive data.
• Consistency risk: Conflicting memories should be ranked by authority and recency rather than silently merged into a potentially false state.

VI. Reasoning Methods — Selecting, Testing, and Revising Conclusions

A. Basic reasoning strategies

Basic reasoning strategies organize inference so that conclusions follow from evidence, rules, calculations, or tested alternatives.

• Deduction: Applies a general rule to a specific case; from “all approved requests have a valid signature” and “request R lacks one,” the system concludes that R is not yet approved.
• Induction: Generalizes from observations; repeated API timeouts suggest a reliability issue, but the conclusion remains probabilistic.
• Abduction: Selects the most plausible explanation for evidence; a 401 response may indicate an expired credential, though other causes must be tested.
• Decomposition: Breaks a complex problem into smaller questions, solves each, and combines the results while preserving dependencies.
• Constraint satisfaction: Represents requirements explicitly and rejects candidates violating any hard constraint, such as budget, date, or type limits.
• Generate-and-test: Produces candidate answers or plans, evaluates them against criteria, and retains the strongest valid candidate.
• Backward reasoning: Starts from the goal and identifies necessary predecessor conditions; deployment requires a passing build, which requires resolved compilation errors.
• Reflection and verification: A separate pass checks assumptions, evidence, arithmetic, schema validity, and goal satisfaction instead of merely restating the answer.
• Tool-grounded reasoning: Calculators, code execution, search systems, databases, and validators should replace unsupported estimation when an authoritative operation is available.
• Selection principle: Use the simplest strategy adequate for the task, adding search, branching, or repeated verification only when error cost and complexity justify them.