Question 1

What is an AI agent, and how does it differ from a simple LLM call?

Accepted Answer

A simple LLM call is a single, stateless input→output: text in, text out, no actions. An AI agent is an LLM placed in a loop with tools, memory, and autonomy — it reasons about a goal, decides which action to take, executes it, observes the result, and repeats until done. The defining property is agency: it chooses its next step based on feedback rather than following a fixed script.

LLM call: prompt → response | Agent: goal → [reason → act → observe] loop → result

What turns an LLM into an agent:
- Tools: ability to act on the world (search, DB, code, APIs).
- Loop/control: iterate over multiple steps toward a goal.
- Memory/state: carry context across steps.
- Autonomy: the model, not hard-coded logic, decides what to do next.

One-liner: "An LLM call answers a question. An agent accomplishes a goal — it plans, uses tools, and adapts across steps. Agent ≈ LLM (reasoning) + tools (acting) + memory (state) + a control loop."

Question 2

What is tool use (function calling) in LLMs, and how does it enable agents?

Accepted Answer

Function calling is a capability where you describe tools to the model as schemas (name + typed JSON parameters), and the model, instead of answering in prose, outputs a structured call — the tool name and arguments. Your code executes it and returns the result to the model. This is the mechanism that lets an LLM act, which is what makes agents possible.

Model outputs: {tool:"get_weather", args:{"city":"Delhi"}} → your code runs it → result fed back → model continues

Why it's foundational:
- Grounding: fetch fresh/exact data instead of hallucinating.
- Offloading: delegate what LLMs are bad at (math, lookups, precise ops) to reliable tools.
- Action: take real-world effects — send email, query DB, run code.

Key nuance: The model doesn't execute anything — it only emits a structured request; your runtime executes and returns the observation. That separation is where permissions, validation, and sandboxing live. (This request→execute boundary is the heart of agent harnesses.)

Question 3

How do you design and define tools for an AI agent?

Accepted Answer

Design tools the way you'd design a clean API for an LLM to read. The model selects and calls tools based entirely on their names, descriptions, and parameter schemas — so those are your control surface. Make them clear, atomic, and minimal.

Principles:
- Precise descriptions: the description is how the model decides when to use a tool — this is the #1 driver of correct selection.
- Typed schema with per-parameter descriptions (and examples) so the model fills args correctly.
- Atomic & single-purpose: one clear job per tool; avoid overlapping tools that confuse selection.
- Minimal set: fewer, well-scoped tools beat a sprawling toolbox (too many → wrong picks).
- Informative errors: return actionable error messages so the model can self-correct.
- Safety by design: scope permissions; gate destructive tools.

Direct to your work: Tool/skill design and loading is exactly the harness layer — clear schemas + curated tool sets are what make an agent reliably pick and call the right thing. (Prakhar's Rowboat skill-loading infra lives right here.)

Question 4

What is the difference between reactive and proactive agents?

Accepted Answer

A reactive agent responds to inputs/events as they arrive — stimulus → response. A proactive agent anticipates and initiates: it pursues goals, plans ahead, and takes action without being explicitly prompted each time (e.g. monitoring a system and acting when a condition arises).

Reactive vs Proactive:
- Trigger — Reactive: External input/event. Proactive: Internal goals, schedules, monitoring.
- Behavior — Reactive: Answers/executes on request. Proactive: Anticipates, initiates, plans.
- Example — Reactive: Chatbot answering a query. Proactive: Agent that watches metrics and alerts/fixes.

Most deployed agents today are reactive. Proactive agents add goal-tracking, scheduling/triggers, and initiative — powerful but higher-risk (they act without a human in the immediate loop), so they need stronger guardrails.

Framing: "Reactive = respond; proactive = initiate. Proactivity unlocks autonomy but raises the stakes — an agent taking unprompted actions needs tighter permissions and monitoring than one that only answers."

Question 5

What is the difference between code-generating agents and tool-calling agents?

Accepted Answer

A tool-calling agent picks from a fixed set of predefined tools via function calling — structured, controlled, auditable, but limited to what you've provided. A code-generating (CodeAct) agent writes and executes actual code to accomplish tasks — vastly more flexible (it can compose arbitrary logic, loops, data manipulation) but riskier and requires sandboxing.

Tool-calling vs Code-generating:
- Action space — Tool-calling: Predefined tools only. Code-generating: Arbitrary code.
- Flexibility — Tool-calling: Bounded. Code-generating: Very high.
- Safety/audit — Tool-calling: Easier (known tools). Code-generating: Needs sandbox; harder to audit.
- Best for — Tool-calling: Well-defined action sets. Code-generating: Open-ended computation, data tasks.

Research (e.g. CodeAct) shows code-generating agents can be more expressive and efficient — a single code block can chain what would be many tool calls. But they can run anything, so isolation is mandatory (see Q25).

When to choose: "Tool-calling for controlled, permissioned action sets; code-gen for open-ended computation where you can't enumerate every operation — provided you sandbox execution. Many modern agents blend both: predef

Question 6

Explain the ReAct (Reasoning + Acting) agent architecture.

Accepted Answer

ReAct (Yao et al., 2022) interleaves reasoning and acting in a loop: the agent produces a Thought (reasoning about what to do), takes an Action (a tool call), receives an Observation (the result), and repeats until it can answer. It's the foundational agent pattern.

Example:
Thought: I need the user's latest order status.
Action: get_order(user_id=123)
Observation: {status: "shipped", eta: "Jul 10"}
Thought: I have the info; I can answer now.
Action: finish("Your order ships and arrives Jul 10.")

Why it works: pure reasoning hallucinates facts; pure acting has no plan. Interleaving lets reasoning decide what to do and interpret results, while actions ground the agent in real data — sharply reducing hallucination and enabling dynamic multi-step tasks.

Modern note: Production ReAct uses native tool/function-calling rather than parsing free-text "Action:" lines. And every observation from an external tool is untrusted input — the ReAct loop is a prime prompt-injection surface (see Q22).

Reference in assignment: outcomeschool.com/blog/react-agent.

Question 7

What is the Plan-and-Execute agent pattern?

Accepted Answer

Plan-and-Execute separates planning from doing: a Planner first generates a complete multi-step plan for the goal, then an Executor carries out the steps (often delegating to tools/sub-agents), with a re-planning step if reality diverges. It contrasts with ReAct, which decides each step on the fly.

Goal → Planner (full plan) → Executor (step 1 → step 2 → …) → Re-plan if needed → Answer

ReAct vs Plan-and-Execute:
- Planning — ReAct: Step-by-step, reactive. Plan-and-Execute: Upfront, then execute.
- Best for — ReAct: Exploratory, short tasks. Plan-and-Execute: Complex, long-horizon tasks.
- Efficiency — ReAct: More LLM calls (think each step). Plan-and-Execute: Fewer (plan once); cheaper reasoning.
- Weakness — ReAct: Can lose the thread. Plan-and-Execute: Rigid if plan is wrong → needs re-planning.

When to use: "Plan-and-execute shines for structured, multi-step tasks where a stable plan helps and you want fewer expensive reasoning calls. Add a re-plan loop so a wrong initial plan doesn't doom the run."

Reference in assignment: outcomeschool.com/blog/plan-and-execute-agent.

Question 8

What is an agent loop, and how does it decide when to stop?

Accepted Answer

The agent loop is the core cycle — reason → act → observe — repeated until a termination condition is met. Deciding when to stop is a critical design concern: without explicit stop conditions, agents loop forever or quit too early.

Stop conditions (use several):
- Task complete: the model emits a "finish"/final-answer signal.
- Max iterations: a hard cap on steps (safety net against loops).
- Budget/time limit: token, cost, or wall-clock ceiling.
- No progress: detect repeated states/actions and halt.
- Human interrupt or tool-signaled completion.

Design rule: "Always combine a model-decided stop (the agent thinks it's done) with hard external limits (max steps, budget). Relying only on the model to stop is how you get infinite loops (Q31)."

Reference in assignment: outcomeschool.com/blog/ai-agent-loop.

Question 9

What is agent reflection, and how does it improve agent performance?

Accepted Answer

Reflection is a pattern where the agent critiques its own output or actions and iterates to improve — generate a draft, evaluate it against criteria (self-critique or an external evaluator/verifier), then revise. It adds a feedback loop that catches errors the first pass missed (the "Reflexion" idea).

Generate → Reflect/critique ("what's wrong?") → Revise → (repeat until good enough)

Why it helps: a single generation commits to the first attempt; reflection lets the model reconsider, catch mistakes, and self-correct — improving quality on coding, writing, and complex reasoning. Using a separate verifier (tests, a critic model, tool feedback) is stronger than pure self-critique, which can be over-confident.

Trade-off: "Reflection trades extra calls (cost/latency) for quality. Ground it in objective feedback where possible — unit tests, tool errors, a verifier — because a model grading its own work is unreliable. Reserve it for high-value or error-prone tasks."

Reference in assignment: outcomeschool.com/blog/reflection-agent.

Question 10

What is agent orchestration, and how do you implement it?

Accepted Answer

Orchestration is coordinating the components of an agentic system — steps, tools, and (in multi-agent setups) multiple agents — into a coherent workflow: routing, sequencing, parallelizing, managing state, and handling handoffs. It's the "conductor" that decides who does what, when, and with what context.

Common patterns:
- Sequential/chain: steps run in order, output → input.
- Router/dispatcher: a classifier routes each request to the right agent/tool.
- Hierarchical (manager–worker): an orchestrator delegates subtasks to specialized workers/sub-agents.
- Parallel fan-out/gather: run independent subtasks concurrently, then merge.
- Graph-based: nodes + conditional edges with shared state (LangGraph, Q20).

Implementation reality: "Orchestration is mostly state management + control flow + handoff contracts. Frameworks like LangGraph model it as a stateful graph; the hard parts are clean handoff schemas, error recovery between steps, and keeping context scoped so agents don't pollute each other." (Core to Rowboat's cowork orchestration.)

Reference in assignment: outcomeschool.com/blog/ai-orchestration.

Question 11

What is AI agent memory, and why do agents need it?

Accepted Answer

LLMs are stateless — they remember nothing between calls. Agent memory is the system that persists information across steps and sessions so the agent stays coherent over long tasks, learns from experience, and personalizes to the user. Without it, an agent forgets everything the moment the context window rolls over.

Memory is what separates a one-shot assistant from a system that can run a long task, resume where it left off, and remember a user across sessions. It's implemented by storing information outside the context window (databases, vector stores) and retrieving the relevant pieces back into context when needed.

Key framing: "The context window is RAM (small, volatile); memory is disk (persistent, retrieved on demand). Agents need both — and managing what moves between them is the real engineering challenge (that's context engineering, Q13)."

Reference in assignment: outcomeschool.com/blog/ai-agent-memory.

Question 12

What are the different types of agent memory (short-term, long-term, episodic)?

Accepted Answer

Agent memory mirrors human memory. Short-term (working) memory is the current context window — recent turns and a scratchpad, ephemeral. Long-term memory persists across sessions in external stores and splits into semantic (facts/knowledge), episodic (past experiences/events), and procedural (learned skills/how-to).

Type — Holds — Where:
- Short-term / working — Current task, recent turns — Context window
- Semantic (long-term) — Facts: user prefs, domain knowledge — Vector DB / store
- Episodic (long-term) — Past interactions/events ("last time…") — Vector DB / log
- Procedural (long-term) — Skills, instructions, how-to — Prompt/skills store

The flow: keep recent context short-term; write durable facts/experiences to long-term; retrieve the relevant slices back into context per step.

Say this: "Working memory = now; semantic = what I know; episodic = what happened; procedural = how to do things. Good agents write to the right store and retrieve just-in-time, rather than stuffing everything into the window."

Question 13

What is Context Engineering?

Accepted Answer

Context engineering is the discipline of curating exactly what goes into the model's context window at each step — retrieved knowledge, memory, tool results, instructions — to maximize signal and minimize noise, cost, and distraction. It's the layer above prompt engineering: prompt engineering optimizes a single instruction; context engineering manages the whole context across a running task.

Core techniques:
- Retrieval / just-in-time loading of only what's relevant now.
- Compaction / summarization of long histories.
- Pruning stale, redundant, or low-signal content.
- Ordering to counter "lost in the middle."
- Structured state instead of trusting free-form recall.

Why it matters: "More context isn't better — long trajectories accumulate stale, distracting tokens that degrade decisions (context rot). Context engineering is about giving the model the right tokens, not the most tokens. Karpathy popularized the term precisely because this is where agent quality is won or lost."

Reference in assignment: outcomeschool.com/blog/context-engineering.

Question 14

What is Harness Engineering in AI?

Accepted Answer

The harness is the runtime software layer around a (frozen) model that turns it into a reliable agent: tool orchestration, memory/state management, context resets, verification gates, sandboxing, permissions, and feedback loops. The mantra: "Agent = Model + Harness." Harness engineering designs the execution environment so an agent can operate autonomously for hours across many context windows.

The three layers: Prompt engineering (what you say) → Context engineering (what the model sees) → Harness engineering (the execution environment)

The first two shape a single turn; the harness shapes whether the agent survives long autonomous runs. Its pillars: tool orchestration with explicit permission boundaries, persistent state/memory across sessions, verification loops, and clean state management between phases.

Interview gold: "Recent industry data attributes ~65% of enterprise agent failures to harness defects — context drift, schema misalignment, state degradation — not to the model's reasoning. Optimizing the model without stabilizing the harness gives diminishing returns. Without a harness, an agent is a demo; with one, it's a product." (This is Prakhar's Rowboat work — skill/t

Question 15

What is the difference between single-agent and multi-agent systems?

Accepted Answer

A single-agent system is one LLM agent with a set of tools handling the whole task. A multi-agent system uses several specialized agents (each with its own role, prompt, tools, and context) that collaborate — coordinated by an orchestrator or via peer communication — to solve a larger problem.

Single-agent vs Multi-agent:
- Structure — Single-agent: One agent + tools. Multi-agent: Specialized agents + coordination.
- Pros — Single-agent: Simple, cheap, easy to debug. Multi-agent: Specialization, parallelism, context isolation.
- Cons — Single-agent: One context does everything. Multi-agent: Coordination overhead, cost, harder to debug.

Multi-agent helps when a task decomposes into distinct expertise (researcher + coder + reviewer), needs parallelism, or benefits from isolated contexts (each agent avoids polluting the others' window).

Honest take: "Don't reach for multi-agent by default — it adds coordination cost, latency, and failure modes (error propagation across agents). Use it when the task genuinely needs specialization/parallelism; otherwise a single well-toolced agent is simpler and more reliable."

Reference in assignment: outcomeschool.com/blog/multi-agent-systems.

Question 16

What are AI SubAgents?

Accepted Answer

SubAgents are specialized child agents that a parent/orchestrator spawns to handle a focused subtask, each with its own context window, tools, and prompt, returning just a result to the parent. They enable task decomposition, context isolation, and parallelism.

Why context isolation is the killer feature: A subagent does its messy, token-heavy work (searching, reading many files, iterating) in its own context, and hands back only a clean summary/result. The parent's context stays lean — it never sees the subagent's intermediate clutter. This keeps the main agent coherent and cheap on large tasks.

When to use: "SubAgents are ideal for large tasks with separable sub-work — 'research these 5 topics' fans out to 5 subagents in parallel, each returning a summary. The parent orchestrates and synthesizes without drowning in detail. Trade-off: orchestration complexity and cost." (Relevant to Rowboat cowork's agent design.)

Reference in assignment: outcomeschool.com/blog/ai-subagents.

Question 17

How do AI agents communicate?

Accepted Answer

In multi-agent systems, agents communicate via structured messages — passed through an orchestrator (centralized) or peer-to-peer (decentralized), often over a shared message bus/blackboard or via explicit handoff artifacts. Emerging standards like A2A (Agent-to-Agent) aim to standardize inter-agent communication, much as MCP standardizes agent-to-tool.

Patterns:
- Orchestrator-mediated: a manager routes messages and assigns work (hub-and-spoke).
- Peer-to-peer: agents message each other directly (needs protocols to avoid chaos).
- Shared state/blackboard: agents read/write a common workspace.
- Handoff artifacts: structured summaries passed between phases.

Design essentials: "Reliable agent communication needs clear message schemas, defined roles, and termination conditions — otherwise agents loop, talk past each other, or amplify errors. Structured handoffs beat free-form chatter. MCP = agent↔tools; A2A = agent↔agent."

Reference in assignment: outcomeschool.com/blog/how-ai-agents-communicate.

Question 18

What is Model Context Protocol (MCP), and how does it standardize tool integration?

Accepted Answer

MCP is an open standard (introduced by Anthropic, Nov 2024; now stewarded under the Linux Foundation) that standardizes how AI apps connect to external tools and data — often called "USB-C for AI" or "LSP for AI." It solves the N×M integration problem: instead of custom glue for every model×tool pair, you build a server once and any MCP-compatible client can use it.

Architecture: Host (AI app, e.g. Claude Desktop/Cursor) → Client (1:1 per server) → Server (exposes capabilities) · JSON-RPC 2.0

- Server primitives: Tools (executable actions), Resources (read-only data/context), Prompts (reusable templates).
- Client primitives: Sampling (server asks host's LLM for a completion), Roots, Elicitation (ask the user).
- Transports: stdio (local process) and Streamable HTTP (remote); capability negotiation at handshake.

You've built one: Prakhar's OpenCollab MCP server is exactly this — expose tools once, any client (Claude Desktop, Cursor) uses them. Be ready to mention it. Security angle to raise: tool descriptions are text the model reads, so they're a prompt-injection / tool-poisoning surface; remote servers need OAuth 2.1 and tool-level RBAC (never rely on prompt trust).

Question 19

How does LangChain work?

Accepted Answer

LangChain is a framework for building LLM applications by composing reusable abstractions — models, prompts, output parsers, tools, retrievers, memory, and agents — plus a huge library of integrations. Its core idea is chaining: wiring these components into pipelines (via LCEL, the LangChain Expression Language) so output flows from one step to the next.

Key pieces:
- Chains: compose LLM calls + logic into pipelines (e.g. RAG: retrieve → prompt → generate).
- Agents: add a tool-use loop where the model chooses actions.
- Integrations: models, vector stores, tools, loaders — batteries included.

Balanced view: "LangChain accelerates standard pipelines (RAG, simple agents) with lots of integrations, but its abstractions can add overhead and obscure control for complex custom flows — which is exactly why LangGraph exists for stateful, controllable agents."

Reference in assignment: outcomeschool.com/blog/how-does-langchain-work.

Question 20

How does LangGraph work, and how do you implement state management in complex agent workflows?

Accepted Answer

LangGraph models an agent as a stateful graph: nodes (functions / LLM calls / tools) connected by edges (including conditional edges for branching), with a shared, typed State object that flows through and is updated by each node. Unlike linear chains, it supports cycles (loops), branching, persistence, and human interrupts — which is what complex agents need.

State management:
- Explicit typed State: a schema the whole graph reads/writes; reducers control how updates merge.
- Checkpointing: durable state so runs can pause, resume, and recover — essential for long/HITL workflows.
- Conditional edges: route based on state (e.g. "if tool failed → retry node").
- Human-in-the-loop: interrupt at a node, wait for approval, resume.
- Time-travel / replay for debugging.

Why graph over chain: "Real agents loop, branch, retry, and need durable state — a linear chain can't express that. LangGraph makes the control flow and state explicit and inspectable, which is exactly what you want for production reliability and debugging."

Reference in assignment: outcomeschool.com/blog/how-does-langgraph-work.

AI Agents

AI Agents