glossary · ai
AI agent (definition)
A system that combines an LLM with memory, planning, and tool access, running in a goal-directed loop until it hits a stopping condition or a guardrail.
An AI agent is not a chatbot with extra steps. It is a system that wraps an LLM in a control loop: perceive a goal, reason about next steps, act using a tool or API call, observe the result, and repeat until the task is done or a boundary is hit. What makes it an agent is the loop. A single LLM call is stateless and terminal; it generates text and stops. An agent persists, branches, and can run for minutes or hours, accumulating context and executing real-world actions along the way.
The distinction matters in interviews because interviewers at AI-native companies (Sierra, Anthropic, OpenAI) are explicitly testing whether you can define structure and failure modes, not just recite marketing language.
The four components, and why each is a PM concern
Every agent has four parts. The loop is what ties them together at runtime.
- LLM: the reasoning engine. It interprets the goal, evaluates tool outputs, and decides what to do next. Its probabilistic nature is the source of most agent failure modes: it can misread an observation, choose the wrong tool, or hallucinate a step that does not exist.
- Memory: what the agent carries between loop iterations. Short-term memory is the context window. Long-term memory is retrieved from a vector store or database. The PM question: what does the agent need to remember, how is that storage scoped per user, and what happens when memory retrieval returns bad context?
- Planning: how the system breaks a goal into subgoals and sequences them. ReAct and chain-of-thought are the dominant patterns. Weak planning produces loops that go in circles; strong planning produces loops that terminate correctly.
- Tool use: the actions the agent can take beyond generating text. Calling a search API, querying a database, writing to a calendar, executing code, sending an email. Tool access is where product scope lives: what the agent is allowed to touch is a product decision, not a default configuration.
The agentic loop
The full runtime cycle is: Perceive (receive the goal and any context) → Reason (decide what action to take) → Plan (break the task into steps if needed) → Act (call a tool or API) → Observe (read the result) → loop back to Reason with the updated context, until a stopping condition or guardrail is reached.
The loop is why agents differ from scripts. A script executes deterministically. An agent reacts to what it observes. That reactivity is what makes agents capable of tasks that branch unpredictably; it is also what makes them capable of cascading failures. If the LLM misreads an observation in step one, every subsequent action compounds that error.
In 2026, agents routinely run for minutes to hours. Duration is the biggest architectural shift from the 2024 era of chat-based AI. Duration multiplies cost, error compounding, and the blast radius of a wrong action.
Autonomy is a design decision, not a setting
Autonomy is a spectrum, not a binary. A system that pauses for user approval after every action is less agentic than one with broad write access and no confirmation step. Where a product sits on that spectrum is a PM call.
The design questions that define autonomy level:
- Which actions are reversible (reading, drafting) and which are not (sending, deleting, paying)?
- Where does a human need to be in the loop, and at what granularity?
- What is the agent’s stopping condition, and who defines done?
- What happens when the agent is uncertain: does it halt, ask, or make a best-guess?
Getting this wrong is the most common agent product failure in 2026. Users handed irreversible actions when they wanted a recommendation will not trust the product again. Users asked to approve every micro-step when they wanted automation will abandon it. Matching autonomy level to user expectations is the product definition question, and it has no correct technical answer.
Agentic AI vs. AI agents
These are not synonyms. Agentic AI is a property: a spectrum describing how goal-directed and autonomous a system is. AI agents are systems deliberately architected to sit at the high end of that spectrum. A single LLM call can be slightly agentic (if it uses chain-of-thought). A multi-step agent with tool access, memory, and a planning layer is an AI agent. Conflating the two in an interview signals the candidate absorbed marketing copy, not the architecture.
Guardrails are PM scope
Guardrails define what an agent is and is not permitted to do. They include: action whitelists (the agent can query but not write), cost caps (terminate if token spend exceeds a threshold), output filters (block certain response categories), and escalation paths (hand off to a human when confidence drops below a threshold).
Deciding where to draw those boundaries is a product decision. The engineering team can implement any set of guardrails you spec; they cannot decide which ones are right for the user’s trust level, the regulatory environment, or the business’s liability exposure. In a Sierra-style interview, you will be asked to design an agent for a regulated scenario (health insurance billing, for example) and expected to define the guardrails alongside the agent’s capabilities.
The PM frame for agents in 2026
Building a working agent is no longer the hard part. In 2026, any motivated team can wire up an LLM, a tool call, and a loop in a few days. The hard questions are upstream and downstream of build.
Upstream: is this a problem users will pay to have solved by an autonomous system, rather than a human or a simpler tool? Downstream: does the agent’s autonomy level match what users actually want, or is it overstepping in ways that destroy trust?
The right frame is not “can we build this loop?” It is: should it loop at all, how far should it go before checking in, and what does success look like for a user who never sees the reasoning trace?
An agent with the wrong job spec (a goal it cannot reliably pursue, tools that exceed the user’s trust, or a stopping condition that does not match what done means to the user) will fail in production even if the architecture is sound. That job spec is a PM artifact, not an engineering one.
Interview answer
strong
"An AI agent is a system that combines an LLM with memory, planning, and tool access, running in a loop: it perceives a goal, reasons about next steps, acts using a tool or API call, observes the result, and iterates until it meets a stopping condition or hits a guardrail. Unlike a single LLM call, the loop means the system can recover, branch, and run across minutes or hours. As a PM, the key design decisions are: what tools does the agent have access to, which actions are reversible versus irreversible, where does a human need to be in the loop, and what does done look like. An agent with the wrong job spec (a goal it cannot reliably pursue, or tools that exceed the user's trust level) will fail even if the architecture is sound. The failure mode I watch for is autonomy mismatch: users handed irreversible actions when they wanted a recommendation will not use the product again."
weak
"An AI agent is an AI that can do things automatically without humans." This fails on every axis. It says nothing about structure (the loop, memory, tools), nothing about the autonomy spectrum, nothing about failure modes, and nothing about the PM decisions that shape how the system behaves. It sounds like a press release. Interviewers at AI-native companies will immediately push: "what makes it different from a script?" Candidates with only the marketing definition have nowhere to go. Saying "autonomous" without grounding it in the control loop, tool access, and guardrails signals the candidate has not worked close to the technology.
What interviewers are actually testing
At Sierra, Anthropic, and OpenAI, agent questions are usually system-design prompts in disguise: “design an agent for a health insurance network helping patients understand billing.” The expected answer includes the agent’s goal definition, its tool access (read-only vs. write, live data vs. cached), its guardrails (regulated vs. unregulated scenarios), and its autonomy level (where it pauses for human confirmation). Candidates who only define the loop pass the vocabulary test; candidates who spec the guardrails and scope pass the product judgment test.
For the guardrail design question specifically, see design agent guardrails and the agent guardrails cheat sheet. For how the viable/lovable lens applies to agentic systems, see feasibility is free.