Agent Basics for Product Managers
Nine articles explaining what agents are, when to use them, how they run, and how product managers can design controllable agent products.
Agent is one of those words everyone has heard and few teams define in the same way.
Some people mean a chatbot that can call tools. Others mean an automated workflow. Some believe a professional persona plus a knowledge base is already an agent. Each view captures one part of the system, but none is sufficient for a real product.
This series is for product managers who need to define, review, or lead agent products. You do not need an algorithm background or a preferred framework. It starts with product decisions: what agents add, which tasks need them, how they act and remember, and what it takes to turn a demo into a dependable product.
One case across the entire series
We will keep returning to one scenario:
A user uploads meeting notes and asks the system to turn them into a PRD that is ready for an engineering review.
What looks like document generation may involve evidence extraction, requirement clarification, separating facts from assumptions, choosing a process, updating artifacts, reviewing quality, and asking for approval. It exposes most of the important problems in an agent product.
Learning path
- Agent Basics: move from one model response to a task that can keep progressing.
- When to Use an Agent: choose a model call, workflow, copilot, or agent.
- How Agent Runs Work: understand runtimes, loops, and stopping conditions.
- Context, Sessions, and Memory: separate working context, task history, memory, and business truth.
- Agents, Skills, Tools, and MCP: separate decisions, methods, actions, and connections.
- Agent Autonomy: choose one agent, specialists, or workflows.
- State Management in Agent Products: design durable state, proposals, approvals, and audit.
- Evaluating and Shipping Agent Products: build evaluations and release gates.
- Case Study: From Meeting Notes to a Reviewable PRD: combine the ideas into a product blueprint.
The system in one picture
User goal
↓
Product layer: objects, identity, permissions, durable state
↓
Agent runtime: context, planning, loops, pause and resume
↓
Skills / workflow: reusable methods and controlled paths
↓
Tools / MCP: information access and real-world actions
↓
Business systems and the outside world
Across every layer: approval, audit, evaluation, cost, observabilityThe model is only one layer. It sets a capability ceiling, but trust depends on what the model can see and do, how state is stored, when execution must stop, and whether the team can detect failures.