Unit 2: Prompt Engineering, Reasoning and Agent Architectures - Subjective Questions

Zero-shot prompting asks a language model to perform a task without providing any worked examples.

Key characteristics:

• The prompt contains an instruction, task description, or question.
• The model relies on knowledge and patterns learned during pretraining.
• It is simple, fast, and economical in terms of prompt tokens.
• Performance depends heavily on the clarity and specificity of the instruction.

Example:

Prompt: Classify the sentiment of the following review as positive, negative, or neutral: The product works exactly as expected and arrived early.

Expected output: Positive

Zero-shot prompting is most effective for common, clearly defined tasks for which the model already possesses sufficient general knowledge.

Few-shot prompting provides a small number of input-output examples before presenting the actual task.

Examples influence the model by demonstrating:

• The intended task and its boundaries.
• The expected output format.
• Relevant labels, terminology, tone, and level of detail.
• Patterns that the model should apply to a new input.

For example, a prompt may show two reviews with their sentiment labels and then ask the model to classify a third review. The model uses the demonstrations as contextual patterns rather than updating its parameters.

Good examples should be accurate, representative, diverse, and consistent. Misleading or poorly formatted examples can cause the model to reproduce errors or infer an unintended pattern.

Zero-shot prompting:

• Supplies instructions but no demonstrations.
• Uses fewer tokens and is easier to construct.
• Works well for familiar, straightforward, and clearly specified tasks.
• May produce inconsistent results for specialized labels or unusual formats.

Few-shot prompting:

• Supplies a small number of demonstrations.
• Consumes more context-window space.
• Clarifies ambiguous requirements and desired output patterns.
• Usually improves consistency on domain-specific classification or formatting tasks.

Selection: Use zero-shot prompting when the task is standard and token efficiency is important. Use few-shot prompting when the task contains unusual labels, nuanced distinctions, strict stylistic expectations, or a format that is easier to demonstrate than describe.

Effective few-shot demonstrations should satisfy the following criteria:

• Correctness: Every example and answer must be accurate.
• Relevance: Examples should closely resemble the target task.
• Coverage: Include important categories, edge cases, and input variations.
• Diversity: Avoid demonstrations that all express the same trivial pattern.
• Consistency: Use uniform labels, reasoning style, and output structure.
• Ordering: Arrange examples so that they do not create accidental biases; placing a highly relevant example near the query can sometimes help.
• Brevity: Include enough information to reveal the pattern without wasting context-window space.

The demonstrations should collectively communicate the intended decision boundary. Unbalanced examples can bias predictions, while contradictory examples may make the model's behavior unstable.

Chain-of-thought prompting encourages a model to generate intermediate reasoning steps before producing a final answer. It is commonly applied to multi-step arithmetic, logical deduction, planning, and symbolic reasoning.

Advantages:

• Breaks a complex problem into manageable steps.
• Can improve performance on multi-stage reasoning tasks.
• Produces an explanation that can help users inspect the result.
• Makes some calculation or assumption errors easier to identify.

Limitations:

• Intermediate text may sound convincing while still being incorrect.
• Longer reasoning increases token use and latency.
• The generated explanation may not faithfully represent the model's actual decision process.
• Exposing unnecessary internal reasoning may be inappropriate in some systems.

A practical alternative is to request a concise rationale, verifiable intermediate results, or a structured solution followed by the final answer.

Zero-shot chain-of-thought adds a general instruction encouraging stepwise analysis without showing a worked example. For instance: Solve the problem carefully, showing the important calculation steps. It is easy to construct but does not prescribe a specific reasoning pattern.

Few-shot chain-of-thought includes worked examples containing intermediate steps and final answers. The demonstrations teach both the task and the expected reasoning structure.

Comparison:

• Zero-shot uses less prompt space, while few-shot consumes more tokens.
• Few-shot offers stronger control over reasoning style and answer format.
• Zero-shot is suitable for general problems; few-shot is useful when a specialized reasoning method is required.
• Both can generate plausible but incorrect reasoning and therefore require verification.

For reliable deployment, the prompt can require explicit assumptions, key intermediate values, and a separately labeled final answer.

A structured prompt generally contains:

1. Role or context: States the perspective or operational setting.
2. Objective: Clearly defines what the model must accomplish.
3. Input data: Separates the source material from the instructions.
4. Constraints: Specifies rules, exclusions, length limits, or allowed information.
5. Output schema: Defines fields, types, labels, or a template.
6. Examples: Demonstrates the intended behavior when necessary.
7. Quality criteria: Explains how a successful answer should be judged.
8. Fallback behavior: States what to do when information is missing or ambiguous.

Clear delimiters should separate instructions from untrusted input. A structured prompt reduces ambiguity, improves repeatability, and makes outputs easier for software systems to validate and process.

Function calling allows a model to request the execution of an application-defined tool using structured arguments. The model selects a tool and proposes arguments, but the surrounding application performs the actual operation.

Interaction cycle:

1. The application provides tool names, descriptions, and parameter schemas.
2. The user submits a request.
3. The model decides whether a tool is required.
4. The model emits a structured call containing the tool name and arguments.
5. The application validates authorization, argument types, ranges, and required fields.
6. The application executes the tool in a controlled environment.
7. The tool result is returned to the model as a tool message.
8. The model interprets the result and prepares the final response.

Function calling connects language understanding with databases, calculators, APIs, and other systems. Because model-generated arguments are untrusted, validation and permission checks must occur before execution.

Schemas specify valid parameters, data types, required fields, and permitted values. They help the model construct predictable calls and allow the host application to reject malformed requests.

Argument validation is essential because model output is probabilistic and must be treated as untrusted. The application should check:

• Required fields and data types.
• Numeric ranges and enumerated values.
• User authorization and resource ownership.
• Unsafe paths, commands, or injected content.

Error handling should return structured, non-sensitive information that allows the model or application to recover. Errors can be classified as invalid arguments, unavailable tools, permission failures, timeouts, or execution failures.

Together, schemas, validation, and error handling improve reliability, security, observability, and graceful recovery.

A conceptual tool definition could contain:

• Name: schedule_meeting — uniquely identifies the operation.
• Description: Explains that the tool creates a calendar event only after the required details are available.
• Title: A required string naming the meeting.
• Start time: A required date-time string with an explicit time zone.
• Duration: A positive integer representing minutes.
• Attendees: An array of validated participant identifiers or email addresses.
• Location: An optional string or meeting-link preference.
• Description: Optional agenda text.
• Confirmation: A required Boolean indicating whether the user approved the final details.

The schema should reject missing time zones, invalid addresses, non-positive durations, and unconfirmed requests. The application must also check calendar permissions and scheduling conflicts. This design separates language interpretation from validated execution and prevents the model from silently creating an event with incomplete details.

Prompt engineering supports task planning by instructing an agent to convert a high-level objective into an ordered set of manageable actions.

A planning prompt should request:

• A precise restatement of the goal.
• Known facts, assumptions, and missing information.
• Subtasks with clear expected outcomes.
• Dependencies and ordering constraints.
• Required tools or resources.
• Success criteria for each step.
• Risks, fallback actions, and stopping conditions.

A useful pattern is plan, execute, observe, and revise. The agent first creates a provisional plan, executes only the next permitted action, observes the result, and updates the remaining plan. This approach is more robust than generating and blindly executing a complete fixed sequence because later actions can incorporate new evidence.

Goal decomposition transforms a broad objective into smaller tasks whose outputs contribute to the final result.

Procedure:

1. Define the final goal and measurable success conditions.
2. Identify required information, artifacts, and constraints.
3. Divide the work into independently understandable subtasks.
4. Determine dependencies among those subtasks.
5. Order or parallelize tasks where appropriate.
6. Assign tools, resources, and expected outputs.
7. Add checkpoints for validation and replanning.

A good plan should be complete, coherent, feasible, ordered, testable, and adaptable. Each step should have a clear completion condition. The plan should avoid redundant actions, respect resource and permission limits, and include recovery paths for likely failures.

Goal-oriented action planning selects a sequence of actions that transforms the current state into a state satisfying a specified goal.

Its major elements are:

• Goal: A desired condition that must become true.
• Current state: Facts currently known about the environment.
• Action: An operation available to the agent.
• Preconditions: Conditions that must hold before an action can execute.
• Effects: Changes to the state caused by the action.
• Cost: Time, money, risk, computational effort, or another quantity associated with the action.

A planner searches for an applicable action sequence whose cumulative effects satisfy the goal, often while minimizing total cost. In real agent systems, actions may correspond to tool calls, and observations after execution update the state used for subsequent planning.

The agent first represents the initial state as verified facts and expresses the goal state as explicit success conditions. It then evaluates actions according to their preconditions, effects, costs, and risks.

Planning process:

1. Select actions whose preconditions hold in the current state.
2. Predict the state resulting from each candidate action.
3. Search forward toward the goal or reason backward from the goal to required preconditions.
4. Compare candidate paths using cost and constraint criteria.
5. Execute the first authorized action.
6. Observe the actual outcome rather than assuming success.
7. Update the state and compare it with the predicted state.
8. Continue, repair the remaining plan, or construct a new plan.

Replanning is necessary when an action fails, new information appears, assumptions become false, or a lower-cost path is discovered. Irreversible or high-impact actions should require additional checks or human approval.

Agent memory is the information retained and retrieved by an agent to maintain continuity, make decisions, and improve task performance.

• Working memory: Temporary information relevant to the current task, such as the active plan, recent observations, and intermediate results.
• Episodic memory: Records of past interactions or events, often including when they occurred and their outcomes.
• Semantic memory: General facts, concepts, user preferences, and distilled knowledge independent of a specific event.
• Procedural memory: Instructions, policies, workflows, or learned methods describing how to perform tasks.

These categories may overlap in implementation. For example, recent messages may be kept directly in the context window, while older experiences are summarized and stored externally for retrieval when relevant.

Major challenges and solutions include:

• Limited context window: Summarize older content and retrieve only relevant memories.
• Irrelevant retrieval: Use semantic similarity together with recency, metadata, task relevance, and importance scores.
• Outdated information: Attach timestamps, version data, and expiration policies.
• Contradictory memories: Preserve provenance and apply conflict-resolution rules rather than silently merging claims.
• Privacy risks: Minimize stored data, obtain consent, encrypt sensitive records, enforce access controls, and support deletion.
• Memory poisoning: Treat retrieved text as untrusted data and separate it from system instructions.
• Unbounded growth: Consolidate duplicates, compress histories, and apply retention limits.

A robust memory system should record not only content but also source, confidence, scope, and time so the agent can judge whether a memory is appropriate for the current decision.

State management is the controlled tracking and updating of information required for an agent to continue a task across multiple reasoning and action cycles.

An agent's state commonly stores:

• The current user goal and constraints.
• The active plan and status of each step.
• Recent observations and tool results.
• Variables and intermediate artifacts.
• Pending questions or unresolved dependencies.
• Completed, failed, and retried actions.
• Resource, time, and token budgets.
• Permissions, approval status, and safety flags.
• References to relevant long-term memories.

State updates should be explicit, validated, and ideally logged. Separating durable state from conversational text improves recovery, enables auditing, and prevents the model from treating an assumed result as an observed fact.

ReAct-style reasoning interleaves analysis, action, and observation. The agent decides the next action using the latest evidence, invokes a tool, observes the result, and repeats.

A plan-first architecture creates a broader sequence of subtasks before execution begins. It then follows the plan, possibly with checkpoints or revisions.

Comparison:

• ReAct is adaptive and useful in uncertain or information-rich environments.
• Plan-first behavior provides stronger global organization for long, dependency-heavy tasks.
• ReAct may become locally focused or repeatedly call tools without sufficient direction.
• A rigid plan-first agent may continue with obsolete assumptions after the environment changes.

A hybrid design is often strongest: produce a high-level plan, execute one step through an action-observation loop, validate the result, and revise the remaining plan when necessary.

Common reasoning strategies include:

• Decomposition: Break a complex problem into smaller subproblems and combine their results.
• Self-consistency: Generate multiple candidate solutions and select the answer supported by the most consistent outcomes.
• Reflection: Review an initial solution for missing constraints, weak assumptions, or likely errors, then revise it.
• Verification: Check claims using calculations, rules, tools, tests, or trusted sources.
• Backward reasoning: Begin with the goal and determine what conditions must be satisfied.
• Analogical reasoning: Adapt the structure of a related solved problem to a new case.

These strategies improve reliability only when applied carefully. Repeated model-generated answers are not independent evidence, and reflection can reinforce an error. External verification is preferable whenever an authoritative tool or source is available.

An end-to-end agent architecture can contain the following components:

1. Input and policy layer: Interprets the request, authenticates the user, and applies safety and permission rules.
2. Goal manager: Converts the request into explicit objectives, constraints, and success criteria.
3. Planner: Decomposes the goal into subtasks with dependencies, tools, and completion checks.
4. State store: Tracks the active plan, observations, intermediate outputs, budgets, and action status.
5. Memory manager: Retrieves relevant past information and stores approved, useful outcomes with provenance.
6. Reasoning controller: Selects the next step and decides whether to answer, retrieve, calculate, ask for clarification, or call a tool.
7. Tool gateway: Validates structured arguments, enforces authorization, executes tools, and normalizes results.
8. Verifier: Checks tool outcomes, factual support, constraints, and completion criteria.
9. Response generator: Produces a concise final answer with appropriate evidence or uncertainty.
10. Audit and recovery layer: Logs decisions, handles failures, supports retries, and requests human approval for high-impact actions.

The control loop is plan, act, observe, update state, verify, and replan. Memory provides relevant context, but retrieved content remains untrusted. This modular architecture improves reliability, security, testability, and observability.